On Sun, Mar 22, 2009 at 02:53:04PM +0100, Peter Palfrader wrote: > On Sun, 22 Mar 2009, Peter Palfrader wrote: > > Core was generated by `schroot > --chroot=sid-alpha-sbuild-7855514e-e68e-40e3-8198-61366cd44074 --recove'. > Program terminated with signal 6, Aborted. > [New process 24735] > #0 0x0000020000452d68 in raise () from /lib/libc.so.6.1 > (gdb) bt > #0 0x0000020000452d68 in raise () from /lib/libc.so.6.1 > #1 0x0000020000454664 in abort () from /lib/libc.so.6.1 > #2 0x00000200004498ec in __assert_fail () from /lib/libc.so.6.1 > #3 0x00000200068628ec in __pthread_tpp_change_priority () from > /lib/libpthread.so.0 > #4 0x0000020006858fc4 in pthread_mutex_lock () from /lib/libpthread.so.0 > #5 0x0000020000511124 in pthread_mutex_lock () from /lib/libc.so.6.1 > #6 0x0000000120078200 in chroot (this=0x12014dd68) at > /usr/include/boost/detail/sp_counted_base_pt.hpp:76 > #7 0x0000000120088474 in sbuild::chroot_plain::clone (this=0x1201399b0) at > ../../../sbuild/sbuild-chroot-plain.h:31
Thanks. Now, this is interesting. clone() creates a copy of a chroot object, returning is as a std::tr1::shared_ptr<>. This is part of libstdc++. However frame #6 shows it in inline code in one of the boost headers. Possibly a mismatch between the C++ TR1 and Boost headers? Possibly a locking bug in libstdc++ or libc6 on Alpha? This isn't, AFAICT now, a bug in schroot. It's actually in the shared_ptr locking code, which makes sense. The locks would need to be thread safe. Where to go from here? Firstly, are we missing any compiler/linker options to be thread-safe? While we are linked against pthreads, do we need to initialise them explicitly in order to use them safely? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
