pthread_cond_timedwait crashing

[Oceanblue]

Hi,

I have a question about timed wait.

I have this bit of code in the application I am porting:

pthread_mutex_lock(&m_mutex);
int rc = pthread_cond_timedwait(&m_condvar, &m_mutex,
&abstimeout); //line 2
pthread_mutex_unlock(&m_mutex);



It is crashing at line 2.

The mysterious thing is that before it crashes it is called previously
too, & then seems to execute fine.

Would anyone have any idea why this might be happening?

Thanks!

[David Turner]

Do you have a stack trace with more details? How are m_condvar, m_mutex and abstimeout defined in your code?

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Oceanblue]

Hi David,

Thanks for the answer.

&m_mutex and &m_condvar are defined earlier in the constructor of the
class as the following:

pthread_mutex_init (&m_mutex, NULL);
pthread_cond_init (&m_condvar, NULL);

&abstimeout is defined as following, (timespec comes from <time.h>)

struct timespec abstimeout;

In the logcat in Android I just see the following messages...
something about signal 7 killing the process, I'm not sure how to get
further stacktrace:

09-13 10:07:30.832: INFO/DEBUG(15721): *** *** *** *** *** *** *** ***
*** *** *** *** *** *** *** ***
09-13 10:07:30.832: INFO/DEBUG(15721): Build fingerprint: 'MOTO/olyatt/
olympus:2.3.4/4.5.91/110625:user/release-keys'
09-13 10:07:30.832: INFO/DEBUG(15721): pid: 15593, tid: 15676 >>>
com.test <<<
09-13 10:07:30.832: INFO/DEBUG(15721): signal 7 (SIGBUS), code 128
(?), fault addr 00000000
09-13 10:07:30.832: INFO/DEBUG(15721): r0 468c646c r1 003f7149 r2
468c646c r3 003f7149
09-13 10:07:30.832: INFO/DEBUG(15721): r4 003c67b4 r5 468c646c r6
468c8d58 r7 468c649c
09-13 10:07:30.832: INFO/DEBUG(15721): r8 003c67b4 r9 00001d38 10
00000001 fp 468c8b40
09-13 10:07:30.832: INFO/DEBUG(15721): ip 80000000 sp 468c6460 lr
8173920d pc 8173706c cpsr 00000030
09-13 10:07:30.832: INFO/DEBUG(15721): d0 3fb7dec34b704d4d d1
bfbd2284f1496e18
09-13 10:07:30.832: INFO/DEBUG(15721): d2 3fc2b181c8a42db8 d3
bfca18fb6a78148c
09-13 10:07:30.832: INFO/DEBUG(15721): d4 3fd5a71051f6470c d5
3fb001d199045028
09-13 10:07:30.832: INFO/DEBUG(15721): d6 3fac72d0c8fdc09e d7
4059be4588c31b8a
09-13 10:07:30.832: INFO/DEBUG(15721): d8 3f40000000000001 d9
0000000000000000
09-13 10:07:30.832: INFO/DEBUG(15721): d10 0000000000000000 d11
0000000000000000
09-13 10:07:30.832: INFO/DEBUG(15721): d12 0000000000000000 d13
0000000000000000
09-13 10:07:30.832: INFO/DEBUG(15721): d14 0000000000000000 d15
0000000000000000
09-13 10:07:30.832: INFO/DEBUG(15721): scr 20000012
09-13 10:07:30.922: INFO/DEBUG(15721): #00 pc 0003706c /
data/data/com.test/lib/libutils.so
09-13 10:07:30.922: INFO/DEBUG(15721): #01 pc 00039208 /
data/data/com.test/lib/libutils.so
09-13 10:07:30.932: INFO/DEBUG(15721): #02 pc 00049e68 /
data/data/com.test/lib/libutils.so
09-13 10:07:30.932: INFO/DEBUG(15721): #03 pc 00027006 /
data/data/com.test/lib/libutils.so
09-13 10:07:30.932: INFO/DEBUG(15721): #04 pc 00011f20 /
data/data/com.test/lib/libutils.so
09-13 10:07:30.932: INFO/DEBUG(15721): code around pc:
09-13 10:07:30.932: INFO/DEBUG(15721): 8173704c 59785971 e9a2f7d9
08490041 f7d91c20
09-13 10:07:30.932: INFO/DEBUG(15721): 8173705c 3504e8fc 2da41c04
e7dbd1f2 1c026803
09-13 10:07:30.932: INFO/DEBUG(15721): 8173706c 6013cb01 46c04770
1c026803 6013cb01
09-13 10:07:30.932: INFO/DEBUG(15721): 8173707c 46c04770 1c026803
6013cb01 46c04770
09-13 10:07:30.932: INFO/DEBUG(15721): 8173708c 881a6803 60033302
14000410 46c04770
09-13 10:07:30.932: INFO/DEBUG(15721): code around lr:
09-13 10:07:30.932: INFO/DEBUG(15721): 817391ec 465fb5f0 464d4656
b4f04644 ad03b085
09-13 10:07:30.932: INFO/DEBUG(15721): 817391fc 1c281c07 92019100
469a9103 ff2ef7fd
09-13 10:07:30.932: INFO/DEBUG(15721): 8173920c 005b23b8 1c2850f8
ff34f7fd 005b23ba
09-13 10:07:30.932: INFO/DEBUG(15721): 8173921c 1c2850f8 ff2ef7fd
005b23bc 1c2850f8
09-13 10:07:30.932: INFO/DEBUG(15721): 8173922c ff28f7fd 005b23be
1c2850f8 ff22f7fd
09-13 10:07:30.932: INFO/DEBUG(15721): stack:
09-13 10:07:30.932: INFO/DEBUG(15721): 468c6420 00000000
09-13 10:07:30.932: INFO/DEBUG(15721): 468c6424 00000000
09-13 10:07:30.932: INFO/DEBUG(15721): 468c6428 00000000
09-13 10:07:30.932: INFO/DEBUG(15721): 468c642c 00000000
09-13 10:07:30.932: INFO/DEBUG(15721): 468c6430 00000000
09-13 10:07:30.932: INFO/DEBUG(15721): 468c6434 00000000
09-13 10:07:30.932: INFO/DEBUG(15721): 468c6438 00000000
09-13 10:07:30.932: INFO/DEBUG(15721): 468c643c 00000000
09-13 10:07:30.932: INFO/DEBUG(15721): 468c6440 00000000
09-13 10:07:30.932: INFO/DEBUG(15721): 468c6444 00000000
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6448 00000000
09-13 10:07:30.942: INFO/DEBUG(15721): 468c644c 00000000
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6450 00000000
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6454 00000000
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6458 df002777
09-13 10:07:30.942: INFO/DEBUG(15721): 468c645c e3a070ad
09-13 10:07:30.942: INFO/DEBUG(15721): #01 468c6460 003f7149
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6464 468c8acc
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6468 00000000
09-13 10:07:30.942: INFO/DEBUG(15721): 468c646c 003f7149
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6470 00000000
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6474 003c67b4
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6478 00001d38
09-13 10:07:30.942: INFO/DEBUG(15721): 468c647c 468c8d58
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6480 468c8b40
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6484 468c8b40
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6488 468c649c
09-13 10:07:30.942: INFO/DEBUG(15721): 468c648c 4590b008
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6490 003f7149
09-13 10:07:30.942: INFO/DEBUG(15721): 468c6494 81749e6d /data/
data/com.test/lib/libutils.so
09-13 10:07:32.382: INFO/DEBUG(15721): debuggerd committing suicide to
free the zombie!
09-13 10:07:32.382: INFO/BootReceiver(1627): Copying /data/tombstones/
tombstone_08 to DropBox (SYSTEM_TOMBSTONE)
09-13 10:07:32.392: ERROR/InputDispatcher(1627): channel '40c0e1f8
com.test/com.abc.SetupScreen (server)' ~ Consumer closed input channel
or an error occurred. events=0x8
09-13 10:07:32.392: ERROR/InputDispatcher(1627): channel '40c0e1f8
com.test/com.abc.SetupScreen (server)' ~ Channel is unrecoverably
broken and will be disposed!
09-13 10:07:32.392: DEBUG/Zygote(1459): Process 15593 terminated by
signal (7)
09-13 10:07:32.402: WARN/GpsLocationProvider(1627): Unneeded remove
listener for uid 1000
09-13 10:07:32.402: INFO/WindowManager(1627): WIN DEATH:
Window{40c0e1f8 com.test/com.abc.SetupScreen paused=false}
09-13 10:07:32.402: ERROR/WifiService(1627): Multicaster binderDied
09-13 10:07:32.402: INFO/ActivityManager(1627): Process com.test (pid
15593) has died.

[David Turner]

This is puzzling, a SIGBUS with fault address 00000000 :-)

It would be interesting to see if you could disassemble the code at address 0003706c in your libutils.so

(you can do that with arm-linux-androideabi-objdump -d -C obj/local/armeabi/libutils.so then search for the address).

My guess is that the machine code is trying to jump to the address in register r10 (which is 00000001).

However, I would expect a SIGSEGV in this case.

This may come from really bad memory corruption though (corrupted stack or even corrupted GOT entries).

Sorry, I can't help you more than that right now.

[fadden]

On Sep 13, 9:22 am, David Turner <di...@android.com> wrote:
> This is puzzling, a SIGBUS with fault address 00000000 :-)

That usually indicates an unaligned access, e.g. a 64-bit integer with
16-bit alignment.

[Oceanblue]

It might very well be the case since we keep running into unaligned
memory access in this code. The parameters of this function are all
well-aligned, but perhaps the memory corruption is happening earlier.

[Tiziano Sardone]

Hi,
you can also try to re-init the mutex when the timedwait return succesfully.

Regards
TiZ

[Oceanblue]

Thanks for the suggestion TiZiano, re-init of the mutex did not
resolve the issue.

Now here's the very strange thing. When I compiled the same code on
NDK-r5b, which was on another machine, it **DOES NOT** give an error.
That line goes through smoothly.

I again recompiled it on my main computer (NDK-r6b), and sure enough,
the code crashes at that line.

Is there any difference in the way mutex & conditional vars are
implemented in the two versions? Would anyone happen to know this?

[Oceanblue]

I resolved the issue. I updated all my tools - SDK, ADT, NDK - &
deleted & rebuilt the libraries & cleaned the eclipse project.
Something must have been messed up in the system.

Thanks everyone for the help.