Oleh Derevenko(deleted)
|
Unexpected result of pthread_mutex_condlock
|
Oleh Derevenko(deleted)
09/27/2010 11:36 AM
post68650
|
Unexpected result of pthread_mutex_condlock
With 6.3.2 procnto-smp on quad-core our QA managed to crash program on assert (repeatable so far) that
pthread_cond_timedwait returns an unexpected error code.
The source lines look like this
timespec tsStopTime;
nsec2timespec(&tsStopTime, ullWaitStopTime);
iWaitRes = pthread_cond_timedwait(&cv->m_cond, &cv->m_mutex, &tsStopTime);
CHECKE(iWaitRes == EOK || iWaitRes == ETIMEDOUT);
The disassembled code is
...
sub $0x4,%esp
lea -0x18(%ebp),%eax // struct timespec
push %eax
pushl -0xc(%ebp) // mutex
mov -0xc(%ebp),%eax
add $0x8,%eax
push %eax // condvar
call 0x804e5a8 <pthread_cond_timedwait@plt>
add $0x10,%esp // Store result
mov %eax,-0x10(%ebp)
cmpl $0x0,-0x10(%ebp) // Check for EOK
je 0x82cf998 <_ZN14CPlatformUtils24WaitCondVarConditionNanoEPvy+190>
cmpl $0x104,-0x10(%ebp) // Check for ETIMEDOUT
je 0x82cf998 <_ZN14CPlatformUtils24WaitCondVarConditionNanoEPvy+190>
sub $0xc,%esp // Fail assertion check
push $0x0
push $0x1
push $0x836e4c0
push $0x619
push $0x836e9c0
call 0x82ca788 <_Z11assert_failPKciS0_bi>
So, the result is stored on stack but there is really not much time and chances for it to get corrupted, + values of
stack variables before and after -0x10+$ebp ('tsStopTime' and 'cv' pointer) look correct.
The condvar with its dedicated mutex look fine
(gdb) p cv[0]
$3 = {m_mutex = {count = -2147483647, owner = 10747906}, m_cond = {count = 2, owner = 4294967291}}
(gdb) x/4wx cv
0x840b308: 0x80000001 0x00a40002 0x00000002 0xfffffffb
Stop time is OK too
(gdb) p tsStopTime
$7 = {tv_sec = 4512764, tv_nsec = 125003096}
But the result returned is somewhat unexpected
(gdb) p iWaitRes
$5 = 33554432
(gdb) x &iWaitRes
0x7fc6d28: 0x02000000
So, the question is: were there any issues of this kind reported/fixed since 6.3.2?
|
|
|