Alan Conway escribió:
Manuel Teira wrote:
Hello.
It seems that the dreaded Mutex initialization assert is not completely
gone. After compiling the unit_test executable, it asserts while trying
to run it, in qpid::sys::Mutex::Mutex(), trying to use a non initialized
recursiveMutexAttr.
The abort stack indicates that it is happening in the
qpid::sys::DeletionManager::AllThreadStatuses int constructor, I suppose
that while creating the static allThreadStatuses object.
Can you post a stack trace and the perror message that went with the failure?
Yes. Sorry for the delay, but I didn't save the core file previous to
the change in the Mutex.h. And since this file is included from a lot of
places I had to recompile again the whole project, that takes near 90
minutes on the hardware I'm using. This is what I get now:
bash-3.00$ ./unit_test
initMutexattr[1](once: 0xffffffff7e14e100, mutexattr: 0xffffffff7e1533d0)
initMutexattr[1](once: 0xffffffff7e14e420, mutexattr: 0xffffffff7e1533e8)
Invalid argument
Assertion failed: 0, file ../../src/qpid/sys/posix/Mutex.h, line 138
Abort (core dumped)
bash-3.00$ pstack core | c++filt
core 'core' of 25632:
/export/home/devel/ws/DSLAP/qpid/trunk/qpid/cpp/src/tests/.libs/unit_t
ffffffff7cdca124 _lwp_kill (6, 0, ffffffff7cdad9d0, ffffffff7cee0000,
ffffffffffffffff, 1800) + 8
ffffffff7cd4620c abort (1, 1b8, 0, 199f00, 0, 0) + 118
ffffffff7cd464b0 _assert (1002d51b1, 1002d51b3, 8a, 0, 199bb8, 0) + 74
00000001000ee444 qpid::sys::Mutex::Mutex #Nvariant 1()
(ffffffff7e14e480, ffffffff7e110938, 0, ffffffff7defe620,
ffffffff7f604f40, 1) + bc
ffffffff7df01c34
qpid::sys::DeletionManager<qpid::sys::PollerHandle>::AllThreadsStatuses::AllThreadsStatuses
#Nvariant 1(int) (ffffffff7e14e480, 0, ffffffff7d910300,
8000000000000000, 1493e0, 80000000) + 24
ffffffff7defe620 __SLIP.INIT_J (0, 0, 0, 0, 0, 0) + 28
ffffffff7df01394 void __STATIC_CONSTRUCTOR() (0, ffffffff7ceeae40,
199648, ffffffff7d3086b4, ffffffff7bb005c0, ffffffff7bb00600) + 4c
ffffffff7df99958 _init (0, 0, ffffffff7f72cac0, ffffffff7f611144,
11f368, ffffffff7bc02030) + 498
ffffffff7f61114c call_init (ffffffff7f72f620, 1, ffffffff7df994c0,
ffffffff7ef01198, ffdfffff, ffffffff7f72cac0) + 1b0
ffffffff7f610614 setup (ffffffff7f72c2e8, ffffffff7f72fd90,
ffffffff7f72cac0, 0, ffffffff7bd011b8, ffffffff7f72c1c0) + 1358
ffffffff7f61ebb8 _setup (12e4b8, b00, 28e30, 100000040, 0,
ffffffff7ffffbd8) + 3a4
ffffffff7f604f10 _rt_boot (0, 0, 0, 0, 0, 0) + 88
0000000000000000 ???????? (0, 0, 0, 0, 0, 0)
This is everything I was able to get, using the pstack utility on the
generated core file, as dbx refuses to cooperate, just SIGSEGV itself
trying to inspect this core file. I didn't try to load the dbx core
inside dbx itself, fearing some relativity effect.
The error is an EINVAL, and trusting the previous logs, it's caused by
the pthread_mutexattr_t not being initialized previously.
I suspect that it has something to do with static initialization order.
So, I replaced the QPID_POSIX_ASSERT_THROW_IF wrapping the
pthread_mutex_init call in qpid::sys::Mutex::Mutex(), to allow the
program to continue, with:
if (pthread_mutex_init(&mutex, recursiveMutexattr) != 0) {
std::cout << "Error initializing mutex: " << &mutex
<< ". " << std::strerror(errno) << std::endl;
}
I also added some logs in the initMutexattr function:
std::cout << "initMutexattr[" << pthread_self() << "](once: "
<< &onceControl << ", mutexattr: " << &mutexattr
<< ")" << std::endl;
in the Mutex constructor and in the AllThreadStatuses constructor to
verify that the mutex is being used before the recursiveMutexAttr gets
initialized:
initMutexattr[1](once: 0xffffffff7e14e300, mutexattr: 0xffffffff7e1535f8)
initMutexattr[1](once: 0xffffffff7e14e620, mutexattr: 0xffffffff7e1535d8)
Mutex::Mutex with mutex at 0xffffffff7e14e680 and pthread_mutex_attr_t
at 0x0000000100400758
Error initializing mutex: 0xffffffff7e14e680. Error 0
AllThreadsStatuses ctor. Mutex: 0xffffffff7e14e680
[snip lots of other initMutexattr and Mutex::Mutex nonrelated calls]
initMutexattr[1](once: 0x00000001003f7730, mutexattr: 0x0000000100400758)
I suspect that the static nature of AllThreadStatuses could be involved.
Any thought?
Order of static initializers would be my favourite suspect also. I'll take a
look when I have a stack trace.
.
