Commented by: @asfernandes

Are you using both versions at the same time?

Commented by: @kattunga

No, first I tested RC2 for a couple of days, when I saw the segfault in the log I uninstall it and then I installed the latest nightly build to test if the bug was fixed after RC2, but the segfault is still there.
At this moment I have installed FB 2.5 Classic nightly build of 07/16

Commented by: @asfernandes

Are there files in /tmp/firebird? What about if you delete them (with Firebird closed) and start it?

Commented by: @dyemanov

Please setup the debug information and provide us with the backtrace when the crash happens the next time.

Commented by: @kattunga

I was investigating a little more and I find that the segfault happens when client close the connection. Not all the time, mostly when conecting from a php web application, but sometimes when connecting from simple clients.
Adriano, yes I delete all files in /tmp/firebird and start it again. That directory have several fb_trace_xxxxx files all the time (I don't have any trace enabled).
I need some help to do a backtrace (I have no idea), could somebody point me to the steps to to get a backtrace?

Commented by: @AlexPeshkoff

http://www.ibphoenix.com/admin/menu.nfs?a=ibphoenix&page=ibp_gdb_linux

Commented by: @AlexPeshkoff

Small addition - 2.5 does not have a problem, mentioned in the end of thet articel - you install debuginfo and work with gdb. Command in gdb to get trace - 'thread apply all bt'.
Also you may try RC3 from prerelease area - http://www.firebirdsql.org/download/prerelease/

Commented by: @kattunga

I attached the core dump and the result of the backtrace, please, let me know if I did it right.
I did it with RC3 from prerelease area

Commented by: @AlexPeshkoff

Christian, please take a look at this:
https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/576346

Firebird crashes in the same funtion __nptl_deallocate_tsd(). Looks like ubuntu 10.04 bug.

Commented by: @kattunga

Alexander, I was thinking that could be an Ubuntu bug too, but in the same machine FB 2.1.3 CS works fine.
Are there differences in FB architecture that could affect FB 2.5?

Commented by: @AlexPeshkoff

Yes, certainly - and true serious in the aspect of this bug. Linux classic server before 2.5 is single-threaded program, which (therefore) never starts new threads, and __nptl_deallocate_tsd() function is therefore never invoked. 2.5 CS is multi-threaded, even when it serves single connection.

Commented by: @kattunga

Big problem....
Any idea if I could upgrade or downgrade any package of ubuntu to confirm this?
Do you know which is the package that contain the library that hold this function?

Commented by: @kattunga

Alexander, I was investigating a little and I didn't found any confirmed bug related with this library and ubuntu, there are some reported bugs in several linux distributions that involves a segfault in this function but none is confirmed.
I'll try to test FB 2.5 against other linux distribution to try to isolate the problem, but it will take me some time because I need time to install them (the only one that I have installed now is ubuntu 10.04 32 bits)
May be, some more fb testers could test if they see this problem in other new linux distributions.

Commented by: @kattunga

Take care, that this segfault doesn't produce any visible error in client side, the only symptom is the kernel.log filled with the error message.

Commented by: @asfernandes

I do use (for FB development) FB 2.5 SuperClassic (fb_smp_server) in Ubuntu 10.04 64bit without problem.

Commented by: @kattunga

I test fb_smp_server and I found that it produce the error when I shut down the service.
So the segfault happens at the moment that the process is destroyed.

Adriano, could you check if when you shutdown firebird, it write an entry in kernel.log with the segfault?

Commented by: @kattunga

I test it on a fresh Ubuntu server 9.10 32bit and problem exist too.

Commented by: @AlexPeshkoff

On gentoo (I currently have glibc-2.10.1 installed) I could not reproduce an issue, running fbtcs which makes hundreds of connections during the run and each connection means classic server start/stop.

So the traditional question comes - what _exactly_ should be done to reproduce your problem? Some specific database operations, may be UDFs, etc. ?

Commented by: @kattunga

From a client application I open a connection, I run a query, then I close the connection and fb_inet_server log a segfault in kernel.log
When using fb_smp_server the segfault is logged in kernel at the moment of shutting down firebird service.

Commented by: @AlexPeshkoff

Sorry, if this is all details you can provide - I can't reproduce it on gentoo.

Commented by: @kattunga

I found the problem that cause the segfault.
The problem was in an old udf compiled with Kilix.
I recompile it width FreePascal and the segfault disappears.
So this bug should be closed as invalid

Commented by: @kattunga

Sorry, I didn't see this before because the udf was linked in several computed fields, so I didn't see it when I run
SELECT * FROM ANYTABLE