Rene Engelhard wrote: > This is weird btw, given it has exactly the same thing on falla. And also > even with gcj-5-jre removed. In an out-of-date sid chroot, with latest openjdk-7, on kfreebsd-9 kernel; I can run the sw_macros_test 100 times without reproducing it. Then I built in a clean, up-to-date sid chroot on another machine, with kfreebsd-10 kernel, and reproduced it the first time, during package build. This is good, from here I can start to eliminate the variables and try again. I attached gdb to the hung cppunittest process (which seemed idle, not in a busy loop), and something is waiting to acquire a mutex; probably a lock held by another thread: | Thread 1 (process 38094): | #0 0x0000000801cbba6a in __syscall__umtx_op () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 | #1 0x0000000801cba2ff in __lll_lock_wait_private () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 | #2 0x0000000801cb66ed in pthread_mutex_lock () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 | #3 0x0000000800a9b63e in osl_acquireMutex (pMutex=<optimized out>) at /«PKGBUILDDIR»/sal/osl/unx/mutex.cxx:99 | #4 0x0000000808af8d8d in osl::Mutex::acquire (this=0xff5ac8) at /«PKGBUILDDIR»/include/osl/mutex.hxx:56 | #5 SalYieldMutex::acquire (this=0xff5ac0) at /«PKGBUILDDIR»/vcl/generic/app/geninst.cxx:46 | #6 0x00000008158797a5 in SolarMutexGuard::SolarMutexGuard (this=<synthetic pointer>) at /«PKGBUILDDIR»/include/vcl/svapp.hxx:1531 | #7 (anonymous namespace)::ImpTimedRefDev::~ImpTimedRefDev (this=0x3efe440, __in_chrg=<optimized out>) | at /«PKGBUILDDIR»/drawinglayer/source/primitive2d/textlayoutdevice.cxx:86 | [...] I'm sure there are other threads running, but gdb doesn't see them, that's a limitation of gdb on kfreebsd at the moment. Attached the full backtrace anyway for now. Regards, -- Steven Chamberlain steven@pyro.eu.org
Attachment:
bt-full.txt.gz
Description: Binary data
Attachment:
signature.asc
Description: Digital signature