Android, opening system library from native code

Question

Good afternoon,

I would really appreciate if anybody can, please, give a clue about what can be happening in the following scenario involving dlopen.

I'm trying to load Android's system's library libmedia.so by calling dlopen("/system/lib/libmedia.so", RTLD_LAZY); from a library (libA) that is statically linked into an upper library (libB) with the ndk. This last library is called by a java application through a JNI.

The problem is that, this call to dlopen, always crashes dumping the following lines:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/yakju/maguro:4.0.4/IMM76I/330937:user/release-keys'
pid: 1642, tid: 1687  >>> net.media.test:my_process <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad

 r0 deadbaad  r1 01250488  r2 80000000  r3 00000000
 r4 00000000  r5 00000027  r6 013dc888  r7 013c4700
 r8 01303274  r9 00000000  10 5b486b38  fp 00000000
 ip ffffffff  sp 5b6fe578  lr 4005af69  pc 400576c8  cpsr 60000030
 d0  5f616964656d6a66  d1  5f67656e5f706466
 d2  775f657461657265  d3  6f5f6c61636f6c72
 d4  20646e756f46203a  d5  436f502065657266
 d6  206e6f6973736553  d7  3578307830207461
 d8  0000000000000000  d9  0000000000000000
 d10 0000000000000000  d11 0000000000000000
 d12 0000000000000000  d13 0000000000000000
 d14 0000000000000000  d15 0000000000000000
 d16 41680f6010000000  d17 3fe0000000000000
 d18 3feff985c46d85eb  d19 3f49e8ee49e85400
 d20 3c87000000000000  d21 3f1145b88564c411
 d22 3e21ee94a0c6d216  d23 bda8fae9be8838d4
 d24 0000000000000000  d25 0000000000000000
 d26 0100010001000100  d27 0100010001000100
 d28 0100010001000100  d29 0100010001000100
 d30 0001000000010000  d31 0001000000010000
 scr 80000012
         #00  pc 000176c8  /system/lib/libc.so
         #01  pc 0001e864  /system/lib/libc.so (__assert2)
code around pc:
400576a8 4623b15c 2c006824 e026d1fb b12368db  \.#F$h.,..&..h#.
400576b8 21014a17 6011447a 48124798 24002527  .J.!zD.`.G.H'%.$
400576c8 f7f47005 2106ef4c efe8f7f5 460aa901  .p..L..!.......F
400576d8 f04f2006 94015380 94029303 eba4f7f5  . O..S..........
400576e8 4622a905 f7f52002 f7f4ebae 2106ef38  .."F. ......8..!
code around lr:
4005af48 41f0e92d 46804c0c 447c2600 68a56824  -..A.L.F.&|D$h.h
4005af58 e0076867 300cf9b5 dd022b00 47c04628  gh.....0.+..(F.G
4005af68 35544306 37fff117 6824d5f4 d1ee2c00  .CT5...7..$h.,..
4005af78 e8bd4630 bf0081f0 00028592 41f0e92d  0F..........-..A
4005af88 fb01b086 9004f602 461f4815 4615460c  .........H.F.F.F
memory map around addr deadbaad:
befcf000-beff0000 [stack]
(no map for address)
ffff0000-ffff1000 [vectors]
stack:
    5b6fe538  4008365c  /system/lib/libc.so
    5b6fe53c  01250488  [heap]
    5b6fe540  0000013f  
    5b6fe544  40059d15  /system/lib/libc.so
    5b6fe548  4008370c  /system/lib/libc.so
    5b6fe54c  4008885c  
    5b6fe550  00000000  
    5b6fe554  4005af69  /system/lib/libc.so
    5b6fe558  00000000  
    5b6fe55c  5b6fe58c  
    5b6fe560  013dc888  [heap]
    5b6fe564  013c4700  [heap]
    5b6fe568  01303274  [heap]
    5b6fe56c  4005a0d5  /system/lib/libc.so
    5b6fe570  df0027ad  
    5b6fe574  00000000  
#00 5b6fe578  4007a5b5  /system/lib/libc.so
    5b6fe57c  5b490368  /data/data/net.media.test/lib/libB.so
    5b6fe580  013dc888  [heap]
    5b6fe584  4005a401  /system/lib/libc.so
    5b6fe588  400836b0  /system/lib/libc.so
    5b6fe58c  fffffbdf  
    5b6fe590  4005e865  /system/lib/libc.so
    5b6fe594  4007a5b5  /system/lib/libc.so
    5b6fe598  5b490368  /data/data/net.media.test/lib/libB.so
    5b6fe59c  4005e869  /system/lib/libc.so
#01 5b6fe5a0  00000061  
    5b6fe5a4  5b490310  /data/data/net.media.test/lib/libB.so
    5b6fe5a8  5b490310  /data/data/net.media.test/lib/libB.so
    5b6fe5ac  00035b80  
    5b6fe5b0  01303274  [heap]
    5b6fe5b4  5b3ed394  /data/data/net.media.test/lib/libB.so
    5b6fe5b8  013c46a8  [heap]
    5b6fe5bc  013dc8ec  [heap]
    5b6fe5c0  5b6fe634  
    5b6fe5c4  00000003  
    5b6fe5c8  01303274  [heap]
    5b6fe5cc  5b3b4ce8  /data/data/net.media.test/lib/libB.so
    5b6fe5d0  5b4be7c0  /data/data/net.media.test/lib/libB.so
    5b6fe5d4  000003bc  
    5b6fe5d8  00000000  
    5b6fe5dc  5b4ceea4  
    5b6fe5e0  5b6fe628  
    5b6fe5e4  00000000

I've checked the path and the library exists and also added LOCAL_LDLIBS += -ldl into libB's Android.mk to allow using dynamic loading. But I got always the same dump.

Thank you in advance for any useful info that you can share.

score 1 · Accepted Answer · answered Aug 12 '12 at 17:04

Just in case this helps somebody, the problem was related to opening the library twice, without closing it before the second load.

This is reflected in the dump by the fault address, that, as you can see, is a clear magic number signalling, in hexspeak, a crash related to bad memory usage.

score 0 · Answer 2 · answered May 26 '12 at 17:30

0

libmedia would appear to be not part of the NDK:

OpenSL is the supported means of playing audio using the NDK.

answered May 26 '12 at 17:30

CommonsWare

986,068
189
2,389
2,491

Thank you CommonsWare for the info, unfortunately what I want to do can't be achieved with current available implementation of OpenSL ES for Android. My intention is to decode a received audio stream, without having to include a codec library, and play it. Then I thought to use system's media library but, as one of the links you provide states, to avoid problems with manufacturer's changes to this library, I though about dynamically load it with dlopen, based on my previous experience on Linux, but faced this problem. Once again, thank you for the info – jcm May 27 '12 at 10:25

Android, opening system library from native code

2 Answers2