Hi Petr, I have some movement to report. -=| Petr Salinger, Tue, Feb 02, 2010 at 07:46:44PM +0100 |=- >> >> firebird2.5 2.5.0.25784~ReleaseCandidate1.ds2-6 behaved the same: >> ../gen/firebird/bin/gbak_static -MODE read_only -R >> ../builds/misc/help.gbak ../gen/firebird/help/help.fdb >> make[3]: *** [../gen/firebird/help/help.fdb] Segmentation fault >> (core dumped) >> >> ˙˙ and built fine on asdfasdf.debian.net. Is it possible to get the >> core dump? Maybe looking into it can sched some light. > > Yes and no. > > Line 472 is call to "dbb_functions(*p)" > > #3 0x00000000005248b6 in Database (this=0x843d5fe28, p=0x843d52020) at > ../src/jrd/../jrd/../jrd/Database.h:472 Thanks for looking! The next upstream release candidate now reliably fails on kfreebsf/amd64 (and builds fine on /i386). The stacktrace is (obtained on asdfasdf.d.n): ========================================================== (gdb) run -MODE read_only -R ../builds/misc/help.gbak ../gen/firebird/help/help.fdb Starting program: /home/dmn/firebird2.5-2.5.0.25920~ReleaseCandidate2.ds2/gen/firebird/bin/gbak_static -MODE read_only -R ../builds/misc/help.gbak ../gen/firebird/help/help.fdb Program received signal ?, Unknown signal. 0x00000008019347d7 in __pthread_sigsuspend () from /lib/libpthread.so.0 (gdb) bt #0 0x00000008019347d7 in __pthread_sigsuspend () from /lib/libpthread.so.0 #1 0x0000000801933668 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x00000008019346e0 in pthread_create@@GLIBC_2.3 () from /lib/libpthread.so.0 #3 0x000000000063d1a8 in ThreadStart::start ( routine=0x462a72 <shutdownThread>, arg=0x0, priority_arg=<value optimized out>, thd_id=0x800a456a0) at ../src/jrd/ThreadStart.cpp:171 #4 0x000000000063d29d in gds__thread_start (entrypoint=0x7fffffffa4d0, arg=0x1f, priority=0, thd_id=0x94016030) at ../src/jrd/ThreadStart.cpp:73 #5 0x0000000000454ad6 in CtrlCHandler (this=0x7fffffffa940, primary=0x0) at ../src/jrd/why.cpp:1004 #6 GlobalPtr (this=0x7fffffffa940, primary=0x0) at ../src/jrd/../common/classes/init.h:127 #7 YEntry (this=0x7fffffffa940, primary=0x0) at ../src/jrd/why.cpp:1036 #8 0x00000000004610d7 in isc_attach_database ( user_status=<value optimized out>, file_length=0, file_name=0x0, public_handle=0x0, dpb_length=24624, dpb=0x0) at ../src/jrd/why.cpp:1373 #9 0x000000000042f083 in open_files (uSvc=0x800a457a8) at ../src/burp/burp.cpp:1905 #10 gbak (uSvc=0x800a457a8) at ../src/burp/burp.cpp:1062 #11 0x00000000004320c2 in main (argc=<value optimized out>, ---Type <return> to continue, or q <return> to quit--- argv=<value optimized out>) at ../src/burp/burpMain.cpp:47 ============================================================= I posted this to upstream devel list[1] and they responded: [1] http://sourceforge.net/mailarchive/forum.php?thread_name=20100309131707.GF3666%40ktnx.net&forum_name=firebird-devel > At the first glance this looks like broken kFreebsd/amd64. This is > the first thread, started by us (it happens is yValve in > CtrlCHandler, in ctor of static instance of this class). Started > thread does nothing except wait for posix semaphore. How did Unknown > signal arriave here - absolutely no idea. > > PS. On freebsd/amd64 I have successfull build. How likely does it seem to you that the problem is in threading stuff on kfreebsd/amd64? Maybe they are right, or maybe my patches[2] adding support to kfreebsd are not quite right. [2] http://git.debian.org/?p=pkg-firebird/2.5.git;a=tree;f=debian/patches;hb=HEAD fix-kfreebsd_hurd-detection, freebsd_targets, install_freebsd_as_linux, maybe also optional_posix_fadv Thank you for your (and anyone else's) help on this! The bug is quite important for the release as the reverse dependencies include such things as php5 and qt4-x11 :|
Attachment:
signature.asc
Description: Digital signature