libspotify.so.12.1.51 segfaults on Android - android

I've modified the jukebox example to run on Android, but it segfaults miserably when trying to call the sp_session_create() function.
Basically - I have a helloworld Android app with a button. When pressed it calls this function, which crashes on sp_session_create():
JNIEXPORT void JNICALL Java_com_holidaystudios_unispot_uniSpot_prepareSpotify() {
sp_session *sp;
sp_error err;
const char *username = NULL;
const char *password = NULL;
username = __USERNAME;
password = __PASSWORD;
g_listname = __PLAYLIST;
UNISPOT_DEBUG("prepareSpotify() - 1\n");
audio_init(&g_audiofifo);
UNISPOT_DEBUG("prepareSpotify() - 2\n");
/* Create session */
spconfig.application_key_size = g_appkey_size;
UNISPOT_DEBUG("prepareSpotify() - 3 %d, %p, %p (%p)\n", g_appkey_size, &spconfig, &sp, sp_session_create);
err = sp_session_create(&spconfig, &sp);
UNISPOT_DEBUG("prepareSpotify() - 4\n");
.
.
.
Here's the logcat output which shows the segfault:
I/UNISPOT|NDK( 5951): prepareSpotify() - 1
I/UNISPOT|NDK( 5951): prepareSpotify() - 2
I/UNISPOT|NDK( 5951): prepareSpotify() - 3 321, 0x575115ac, 0xbec4052c (0x5b4107b4)
F/libc ( 5951): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)
I/DEBUG (31750): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG (31750): Build fingerprint: 'google/yakju/maguro:4.0.4/IMM76I/330937:user/release-keys'
I/DEBUG (31750): pid: 5951, tid: 5951 >>> com.holidaystudios.unispot <<<
I/DEBUG (31750): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG (31750): r0 0155d708 r1 4006162c r2 00000000 r3 5b47add8
I/DEBUG (31750): r4 0155d708 r5 5b47e740 r6 57508d48 r7 0155d708
I/DEBUG (31750): r8 bec40460 r9 bec4052c 10 0155d768 fp 0155d768
I/DEBUG (31750): ip 40061474 sp bec40340 lr 5b410a7c pc 5b4104f4 cpsr 60000010
I/DEBUG (31750): d0 00656c6f736e6f63 d1 72616364732f2061
I/DEBUG (31750): d2 61726f74532f2f63 d3 7865646e692f6568
I/DEBUG (31750): d4 0000000000000000 d5 0000000000000000
I/DEBUG (31750): d6 0000000000000000 d7 00f92b8000000000
I/DEBUG (31750): d8 0000000000000000 d9 0000000000000000
I/DEBUG (31750): d10 0000000000000000 d11 0000000000000000
I/DEBUG (31750): d12 0000000000000000 d13 0000000000000000
I/DEBUG (31750): d14 0000000000000000 d15 0000000000000000
I/DEBUG (31750): d16 416f257010000000 d17 3fe0000000000000
I/DEBUG (31750): d18 0000000000000000 d19 3fe5555560000000
I/DEBUG (31750): d20 0000000000000000 d21 0000000000000000
I/DEBUG (31750): d22 3ff0000000000000 d23 0000000000000000
I/DEBUG (31750): d24 0000000000000000 d25 3fe5555560000000
I/DEBUG (31750): d26 0000000000000000 d27 3fe5555560000000
I/DEBUG (31750): d28 0000000000000000 d29 3ff0000000000000
I/DEBUG (31750): d30 3ff0000000000000 d31 be23e4f5df600000
I/DEBUG (31750): scr 80000013
I/DEBUG (31750):
I/DEBUG (31750): #00 pc 0016b4f4 /data/data/com.holidaystudios.unispot/lib/libspotify.so
I/DEBUG (31750): #01 lr 5b410a7c /data/data/com.holidaystudios.unispot/lib/libspotify.so
I/DEBUG (31750):
I/DEBUG (31750): code around pc:
I/DEBUG (31750): 5b4104d4 e59f50ac e59f30ac e08f5005 e7953003 .P...0...P...0..
I/DEBUG (31750): 5b4104e4 e5902004 e2833008 e5803000 e1a04000 . ...0...0...#..
I/DEBUG (31750): 5b4104f4 e5923000 e1a00002 e1a0e00f e593f178 .0..........x...
I/DEBUG (31750): 5b410504 e5943004 e3530000 0a000005 e3a02000 .0....S...... ..
I/DEBUG (31750): 5b410514 e1a00003 e5842004 e5933000 e1a0e00f ..... ...0......
I/DEBUG (31750):
I/DEBUG (31750): code around lr:
I/DEBUG (31750): 5b410a5c ebfaaa07 e5c7822c e1a00007 ebfffdec ....,...........
I/DEBUG (31750): 5b410a6c e3500000 1a000005 e1a00007 ebfffe94 ..P.............
I/DEBUG (31750): 5b410a7c e1a00007 ebfc951c e3a04002 ea00009d .........#......
I/DEBUG (31750): 5b410a8c e1a01006 e4d13001 e5c73064 e3a02080 .....0..d0... ..
I/DEBUG (31750): 5b410a9c e2870065 ebfaa8ee e3a020c0 e2861081 e........ ......
I/DEBUG (31750):
I/DEBUG (31750): stack:
I/DEBUG (31750): bec40300 0155d9c8 [heap]
I/DEBUG (31750): bec40304 5b37f080 /data/data/com.holidaystudios.unispot/lib/libspotify.so
I/DEBUG (31750): bec40308 0155d708 [heap]
I/DEBUG (31750): bec4030c 5b47e740 /data/data/com.holidaystudios.unispot/lib/libspotify.so
I/DEBUG (31750): bec40310 57508d48 /data/data/com.holidaystudios.unispot/lib/liblespot.so
I/DEBUG (31750): bec40314 5b410230 /data/data/com.holidaystudios.unispot/lib/libspotify.so
I/DEBUG (31750): bec40318 00000400
I/DEBUG (31750): bec4031c bec40460 [stack]
I/DEBUG (31750): bec40320 bec4052c [stack]
I/DEBUG (31750): bec40324 0155d768 [heap]
I/DEBUG (31750): bec40328 0155d768 [heap]
I/DEBUG (31750): bec4032c 5b33f988 /data/data/com.holidaystudios.unispot/lib/libspotify.so
I/DEBUG (31750): bec40330 00000000
I/DEBUG (31750): bec40334 00040000
I/DEBUG (31750): bec40338 df0027ad
I/DEBUG (31750): bec4033c 00000000
I/DEBUG (31750): #00 bec40340 575115ac /data/data/com.holidaystudios.unispot/lib/liblespot.so
I/DEBUG (31750): bec40344 5b47e740 /data/data/com.holidaystudios.unispot/lib/libspotify.so
I/DEBUG (31750): bec40348 57508d48 /data/data/com.holidaystudios.unispot/lib/liblespot.so
I/DEBUG (31750): bec4034c 5b410a7c /data/data/com.holidaystudios.unispot/lib/libspotify.so
I/DEBUG (31750): bec40350 00000000
I/DEBUG (31750): bec40354 57e90026 /system/framework/framework.odex
I/DEBUG (31750): bec40358 41678018 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG (31750): bec4035c bec404e4 [stack]
I/DEBUG (31750): bec40360 00000000
I/DEBUG (31750): bec40364 00010001
I/DEBUG (31750): bec40368 00000000
I/DEBUG (31750): bec4036c 00000000
I/DEBUG (31750): bec40370 416a9ee8 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG (31750): bec40374 416a9ee8 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG (31750): bec40378 41678018 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG (31750): bec4037c 00000024
I/DEBUG (31750): bec40380 01303740 [heap]
I/DEBUG (31750): bec40384 408a39b8
I/BootReceiver( 189): Copying /data/tombstones/tombstone_00 to DropBox (SYSTEM_TOMBSTONE)
I/WindowManager( 189): WIN DEATH: Window{416abe40 com.holidaystudios.unispot/com.holidaystudios.unispot.uniSpot paused=false}
I/ActivityManager( 189): Process com.holidaystudios.unispot (pid 5951) has died.
Any ideas?

I'm posting this as an answer since it seems I need more reputation to answer comments, but, to answer #KurtCobain's request: you also need to make sure that your cache_location and settings_location point to a valid, writable location on your android device. The default value in the spotify examples for those variables is "tmp". This won't work and will cause your app to crash.
Instead (at least as a temporary, straightforward solution) you could use something like Context.getCacheDir in your activity to retrieve a valid temporary folder, and use this value in your C code (see this question for more info on that).

I finally figured out what the problem is. If your AndroidManifest.xml does not request the INTERNET permission (and possibly WRITE_EXTERNAL_STORAGE) it will crash... Unfortunately libspotify does not perform any checks on creating sockets and will therefore crash... I'd say it's actually a bug in libspotify... But anyhoo - here's what you need to add to your AndroidManifest.xml if you are having the same problem as I did:
<uses-permission android:name="android.permission.INTERNET" />
Possibly also this:
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

Related

Unity Game Crashes after Unity Loading Splash Screen Finishes

I've tried all sorts of player setting changes and any small tweaks to try and get my Unity game to run, but I consistently get this segfault crash dump right after the load screen about a VSync related method in libunity.so. I have tried changing the VSync Count setting in Quality, but that changes nothing. Thanks ahead of time for any help.
I/DEBUG ( 323): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 323): Build fingerprint: 'samsung/d2uc/d2att:4.3/######/###########:user/release-keys'
I/DEBUG ( 323): Revision: '16'
I/DEBUG ( 323): pid: 15148, tid: 15148, name: s.SubVer.Covert >>> es.SubVer.Covert <<<
I/DEBUG ( 323): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG ( 323): r0 00000001 r1 40109f24 r2 00000001 r3 0000001d
I/DEBUG ( 323): r4 00000000 r5 64b5bf28 r6 71253503 r7 64b73ec8
I/DEBUG ( 323): r8 000004a2 r9 4180cc58 sl 71253503 fp 000004a2
I/DEBUG ( 323): ip 498f60ac sp beb7afd8 lr 48e53b0c pc 48e54a44 cpsr 800e0010
I/DEBUG ( 323): d0 aaaaaaaaaaaaaaaa d1 aaaaaaaaaaaaaaaa
I/DEBUG ( 323): d2 000003e800000000 d3 0000000000000014
I/DEBUG ( 323): d4 0000000000000000 d5 0000000000000000
I/DEBUG ( 323): d6 431780003f13a403 d7 000000003f800000
I/DEBUG ( 323): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 323): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 323): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 323): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 323): d16 0000000000000000 d17 000004a271253503
I/DEBUG ( 323): d18 002e00640069006f d19 002e006900750067
I/DEBUG ( 323): d20 0061007200470049 d21 0063006900680070
I/DEBUG ( 323): d22 0066006600750042 d23 0072005000720065
I/DEBUG ( 323): d24 0000000000000000 d25 0000008f0000008f
I/DEBUG ( 323): d26 0707070703030303 d27 0000000000000000
I/DEBUG ( 323): d28 0301010101000000 d29 00024e9000024e90
I/DEBUG ( 323): d30 0001000000010000 d31 0001000000010000
I/DEBUG ( 323): scr 60000012
I/DEBUG ( 323):
I/DEBUG ( 323): backtrace:
I/DEBUG ( 323): #00 pc 004eea44 /data/app-lib/es.SubVer.Covert-1/libunity.so (nativeAddVSyncTime(_JNIEnv*, _jobject*, long long)+24)
I/DEBUG ( 323): #01 pc 00010b78 /data/dalvik-cache/data#app#es.SubVer.Covert-1.apk#classes.dex
I/DEBUG ( 323):
I/DEBUG ( 323): stack:
I/DEBUG ( 323): beb7af98 64b73ec8 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7af9c 000004a2
I/DEBUG ( 323): beb7afa0 4cc5d550 [anon:libc_malloc]
I/DEBUG ( 323): beb7afa4 00000024
I/DEBUG ( 323): beb7afa8 00000016
I/DEBUG ( 323): beb7afac 00000024
I/DEBUG ( 323): beb7afb0 4cc5d550 [anon:libc_malloc]
I/DEBUG ( 323): beb7afb4 4012da0c /system/lib/libc.so (pthread_setspecific+164)
I/DEBUG ( 323): beb7afb8 4cc5d550 [anon:libc_malloc]
I/DEBUG ( 323): beb7afbc 00130770
I/DEBUG ( 323): beb7afc0 71253503 /dev/kgsl-3d0
I/DEBUG ( 323): beb7afc4 48e53afc /data/app-lib/es.SubVer.Covert-1/libunity.so (NativeRuntimeException::GetExceptionState()+96)
I/DEBUG ( 323): beb7afc8 00000039
I/DEBUG ( 323): beb7afcc 64b5bf28 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7afd0 df0027ad
I/DEBUG ( 323): beb7afd4 00000000
I/DEBUG ( 323): #00 beb7afd8 00000039
I/DEBUG ( 323): beb7afdc 64b5bf28 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7afe0 64b74010 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7afe4 64b73ec8 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7afe8 649fd688 /dev/ashmem/dalvik-zygote space (deleted)
I/DEBUG ( 323): beb7afec 48458b7c /data/dalvik-cache/data#app#es.SubVer.Covert-1.apk#classes.dex
I/DEBUG ( 323): #01 beb7aff0 64b58310 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7aff4 00000001
I/DEBUG ( 323): beb7aff8 beb7b564 [stack]
I/DEBUG ( 323): beb7affc 64b5bf28 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7b000 00000005
I/DEBUG ( 323): beb7b004 64b5bf28 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7b008 64b74010 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7b00c 64b73ec8 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7b010 649fd688 /dev/ashmem/dalvik-zygote space (deleted)
I/DEBUG ( 323): beb7b014 71253503 /dev/kgsl-3d0
I/DEBUG ( 323): beb7b018 000004a2
I/DEBUG ( 323): beb7b01c 48461b1b /data/dalvik-cache/data#app#es.SubVer.Covert-1.apk#classes.dex
I/DEBUG ( 323): beb7b020 64b73ec8 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7b024 64b5bf28 /dev/ashmem/dalvik-alloc space (deleted)
I/DEBUG ( 323): beb7b028 71253503 /dev/kgsl-3d0
I/DEBUG ( 323): beb7b02c 000004a2
So I figured it out. Turns out, my phone was running out of memory which was causing this segfault. A good lesson for me to remember to compress my textures.

Advanced Android crash analysis?

Is there a way to get more useful information from an android crash? Deliberately inducing a UAF crash in android ICS I get the following output to my logcat, but is there a way to do a more complete stack dump and heap dump at the time of the crash? I can't seem to do it in ddms because as soon as the fatal signal is hit ddms abandons the process (because it doesn't exist anymore)
F/libc ( 598): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)
I/DEBUG ( 33): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEUG ( 33): Build fingerprint: 'generic/sdk/generic:4.0.2/ICS_MR0/229537:eng/test-keys'
I/DEBUG ( 33): pid: 598, tid: 621 >>> com.android.browser <<<
I/DEBUG ( 33): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG ( 33): r0 4b7824f0 r1 004b6da0 r2 00000000 r3 00000000
I/DEBUG ( 33): r4 00e8d7c0 r5 004b6da0 r6 00348370 r7 00000000
I/DEBUG ( 33): r8 49c61b10 r9 4afc808d 10 497df75d fp 00108698
I/DEBUG ( 33): ip 00000000 sp 4b7824f0 lr 496bf215 pc 00000000 cpsr 20000010
I/DEBUG ( 33): d0 44750000cf000000 d1 44c1000000000000
I/DEBUG ( 33): d2 0000000044c10000 d3 4475000044750000
I/DEBUG ( 33): d4 0000000000000000 d5 44c1000000000000
I/DEBUG ( 33): d6 0000000000000000 d7 0000000000000000
I/DEBUG ( 33): d8 0000000000000000 d9 3fa999999999999a
I/DEBUG ( 33): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 33): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 33): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 33): scr 60000013
I/DEBUG ( 33):
I/DEBUG ( 33): #00 pc 00000000
I/DEBUG ( 33): #01 pc 00191212 /system/lib/libwebcore.so
I/DEBUG ( 33): #02 pc 001745c8 /system/lib/libwebcore.so
I/DEBUG ( 33): #03 pc 002b1766 /system/lib/libwebcore.so
I/DEBUG ( 33): #04 pc 004dccae /system/lib/libwebcore.so
I/DEBUG ( 33): #05 pc 004e052a /system/lib/libwebcore.so
I/DEBUG ( 33): #06 pc 004c3aae /system/lib/libwebcore.so
I/DEBUG ( 33): #07 pc 004c3b34 /system/lib/libwebcore.so
I/DEBUG ( 33):
I/DEBUG ( 33): code around pc:
I/DEBUG ( 33): 00000000 ffffffff ffffffff ffffffff ffffffff
I/DEBUG ( 33): 00000010 ffffffff ffffffff ffffffff ffffffff
I/DEBUG ( 33): 00000020 ffffffff ffffffff ffffffff ffffffff
I/DEBUG ( 33): 00000030 ffffffff ffffffff ffffffff ffffffff
I/DEBUG ( 33): 00000040 ffffffff ffffffff ffffffff ffffffff
I/DEBUG ( 33):
I/DEBUG ( 33): code around lr:
I/DEBUG ( 33): 496bf1f4 47904668 bd0e9801 68c3b507 b1134601
I/DEBUG ( 33): 496bf204 fc64f004 6800e005 20b0f8d0 47904668
I/DEBUG ( 33): 496bf214 bd0e9800 68c3b510 f004b113 e001fc49
I/DEBUG ( 33): 496bf224 fd18f7fe bf00bd10 68c3b510 f004b113
I/DEBUG ( 33): 496bf234 e001fc31 fd04f7fe bf00bd10 0124f1a1
I/DEBUG ( 33):
I/DEBUG ( 33): stack:
I/DEBUG ( 33): 4b7824b0 00738f28
I/DEBUG ( 33): 4b7824b4 00348370
I/DEBUG ( 33): 4b7824b8 00000000
I/DEBUG ( 33): 4b7824bc 49c61b10
I/DEBUG ( 33): 4b7824c0 4afc808d
I/DEBUG ( 33): 4b7824c4 497df75d /system/lib/libwebcore.so
I/DEBUG ( 33): 4b7824c8 00108698
I/DEBUG ( 33): 4b7824cc 49857421 /system/lib/libwebcore.so
I/DEBUG ( 33): 4b7824d0 00e7c388
I/DEBUG ( 33): 4b7824d4 00000000
I/DEBUG ( 33): 4b7824d8 00e7c388
I/DEBUG ( 33): 4b7824dc 498573f9 /system/lib/libwebcore.so
I/DEBUG ( 33): 4b7824e0 00e7c388
I/DEBUG ( 33): 4b7824e4 00000000
I/DEBUG ( 33): 4b7824e8 df0027ad
I/DEBUG ( 33): 4b7824ec 00000000
I/DEBUG ( 33): #01 4b7824f0 004b6da0
I/DEBUG ( 33): 4b7824f4 00000001
I/DEBUG ( 33): 4b7824f8 00000000
I/DEBUG ( 33): 4b7824fc 496a25cd /system/lib/libwebcore.so
You can see the complete logs of the device by selecting All messages(no filters) option in Logcat.

Using malloc / free in android

I use malloc() to allocate memory, when I am doing, I use 'free() to free memory.
When I free it, I get 'ABORTING LIBC'.
I print out the value of address when I alloc and free, it is 0x410f1008.
But when I free it, it is freeing 0x410f1000, why is that?
D/ ( 3076): build_: alloc 0x410f1008
...
D/ ( 3076): build: free 0x410f1008
F/libc ( 3076): ### ABORTING: LIBC: ARGUMENT IS INVALID HEAP ADDRESS IN dlfree addr=0x410f1000
F/libc ( 3076): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 3076 (test)
I/DEBUG ( 1647): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 1647): Build fingerprint: ''
I/DEBUG ( 1647): Revision: '0'
I/DEBUG ( 1647): pid: 3076, tid: 3076, name: test >>> test <<<
I/DEBUG ( 1647): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
I/DEBUG ( 1647): r0 00000055 r1 be960720 r2 00000003 r3 deadbaad
I/DEBUG ( 1647): r4 400fa228 r5 410f1000 r6 be960748 r7 400ed73a
I/DEBUG ( 1647): r8 410f1008 r9 ffffff82 sl 000829a0 fp 000007e0
I/DEBUG ( 1647): ip 00000000 sp be960748 lr 400d9a29 pc 400bdffc cpsr 00000030
I/DEBUG ( 1647): d0 3830303166303134 d1 65696c63204d4d20
I/DEBUG ( 1647): d2 0000000000000066 d3 0000000000000072
I/DEBUG ( 1647): d4 0000000000000000 d5 0000000000000000
I/DEBUG ( 1647): d6 0000000000000000 d7 94e7c71700000000
I/DEBUG ( 1647): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 1647): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 1647): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 1647): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 1647): d16 c1dac60e3a4fdf3b d17 3f50624dd2f1a9fc
I/DEBUG ( 1647): d18 41a9f539c0000000 d19 0000000000000000
I/DEBUG ( 1647): d20 0000000000000000 d21 0000000000000000
I/DEBUG ( 1647): d22 0000000000000000 d23 0000000000000000
I/DEBUG ( 1647): d24 0000000000000000 d25 0000000000000000
I/DEBUG ( 1647): d26 0000000000000000 d27 0000000000000000
I/DEBUG ( 1647): d28 0000000000000000 d29 0000000000000000
I/DEBUG ( 1647): d30 0000000000000000 d31 0000000000000000
I/DEBUG ( 1647): scr 00000010
I/DEBUG ( 1647):
I/DEBUG ( 1647): backtrace:
I/DEBUG ( 1647): #00 pc 0000effc /system/lib/libc.so
I/DEBUG ( 1647): #01 pc 00011da3 /system/lib/libc.so (dlfree+1458)
I/DEBUG ( 1647): #02 pc 0000cf13 /system/lib/libc.so (free+10)
I/DEBUG ( 1647): #03 pc 00002c25 /system/bin/ppm2jpg
I/DEBUG ( 1647): #04 pc 0000316d /system/bin/ppm2jpg
I/DEBUG ( 1647): #05 pc 0001271f /system/lib/libc.so (__libc_init+38)
I/DEBUG ( 1647): #06 pc 00000b3c /system/bin/ppm2jpg
I/DEBUG ( 1647):
I/DEBUG ( 1647): stack:
I/DEBUG ( 1647): be960708 00000001
I/DEBUG ( 1647): be96070c 400ed73a /system/lib/libc.so
I/DEBUG ( 1647): be960710 410f1008
I/DEBUG ( 1647): be960714 400d9a93 /system/lib/libc.so
I/DEBUG ( 1647): be960718 00000010
I/DEBUG ( 1647): be96071c 00000007
I/DEBUG ( 1647): be960720 be96071c [stack]
I/DEBUG ( 1647): be960724 00000001
I/DEBUG ( 1647): be960728 400ed336 /system/lib/libc.so
I/DEBUG ( 1647): be96072c 00000005
I/DEBUG ( 1647): be960730 be960754 [stack]
I/DEBUG ( 1647): be960734 0000004f
I/DEBUG ( 1647): be960738 400fa228
To understand this scenario, I debugged the dlmalloc as it is most widely used and we do have source code available in public domain.
ftp://g.oswego.edu/pub/misc/malloc.c
#include"dlmalloc.h"
#include<string.h>
void use_dlmalloc(void){
size_t sz = 32;
char* a = (char*)malloc(32);
strcpy(a,"DougLeaMalloc");
free(a);
}
int main() {
use_dlmalloc();
return 0;
}
The below is the snapshot from GDB session. We can see that the malloc has returned the
0x60c010 and internally while freeing the memory allocator has moved back the pointer by two word(in this 16 byte as mine is 64 bit machine). So the internally
it is actually freeing the 0x60c000. This matches with your problem and the only difference is you are getting the 8 byte difference as your machine should be 32 bit.
(gdb) step
use_dlmalloc () at client.c:5
5 size_t sz = 32;
(gdb) n
6 char* a = (char*)malloc(32);
(gdb)
7 strcpy(a,"DougLeaMalloc");
(gdb) p a
$1 = 0x60c010 ""
(gdb) n
8 free(a);
(gdb) step
free (mem=0x60c010) at dougleamalloc.c:4684
4684 if (mem != 0) {
(gdb) bt
#0 free (mem=0x60c010) at dougleamalloc.c:4684
#1 0x00000000004096f4 in use_dlmalloc () at client.c:8
#2 0x00000000004096ff in main () at client.c:12
(gdb) n
4685 mchunkptr p = mem2chunk(mem);
(gdb) p p
$3 = (mchunkptr) 0x60c000
(gdb) n
4697 if (RTCHECK(ok_address(fm, p) && ok_inuse(p))) {
mem2chunk is marco and defined as follows. This means TWO_SIZE_T_SIZES would be two word(16 byte on 64 bit machine and 8 on 32 bit machine). This macro basically shifts the pointer back.
#define mem2chunk(mem) ((mchunkptr)((char*)(mem) - TWO_SIZE_T_SIZES))
This the structure of the malloc chunk. When it allocates it return the address to user
pointed by arrow. Just prior to that it store all important information like the size
of chunk, status of chunk(free-allocated) and some additional housekeeping information.
struct malloc_chunk {
size_t prev_foot; /* Size of previous chunk (if free). */
size_t head; /* Size and inuse bits. */
struct malloc_chunk* fd; =============> This address returned by malloc.
struct malloc_chunk* bk;
};
While freeing user passes the returned address from malloc(). Now heap allocator internally
moves back the pointer by 8 or 16 byte so that he can fetch all housekeeping information about the chunk. This is boundary tag method and you can read and understand many good concept by reading the comment in his code.
I think this explain your why the address has shifted from malloc to free(). However I do not have idea why on android you are getting 'ABORTING LIBC' message. Hope the above explanation would be useful.

EGL display not valid in Native Activity on Android

I have the following Project I am working on. I am trying to do a simple 2D TriandleFan box.
However, when I run the project the following line fails...
this->display = display;
I can't see why it is failing can anyone else see it?
F/libc ( 5178): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 5191 (gleason.gles.na)
I/ActivityManager( 278): Displayed com.gleason.gles.na/android.app.NativeActivity: +826ms
I/DEBUG ( 35): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 35): Build fingerprint: 'generic/sdk/generic:4.2.2/JB_MR1.1/576024:eng/test-keys'
I/DEBUG ( 35): Revision: '0'
I/DEBUG ( 35): pid: 5178, tid: 5191, name: UNKNOWN >>> com.gleason.gles.na <<<
I/DEBUG ( 35): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG ( 35): r0 00000001 r1 00000000 r2 4045e6cc r3 404608a8
I/DEBUG ( 35): r4 00003038 r5 00001f90 r6 2a027378 r7 00000000
I/DEBUG ( 35): r8 4924ae1c r9 00100000 sl 2a027378 fp 00000016
I/DEBUG ( 35): ip 00000000 sp 4924adf0 lr 40427f29 pc 491468ae cpsr 00000030
I/DEBUG ( 35): d0 3f8000003f800000 d1 3ff000003f800000
I/DEBUG ( 35): d2 3ff0000000000000 d3 bf62cda764a98eab
I/DEBUG ( 35): d4 4000000000000000 d5 3f40000000000000
I/DEBUG ( 35): d6 3fe999999999999a d7 3f8000003f800000
I/DEBUG ( 35): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 35): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 35): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 35): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 35): scr 60000010
I/DEBUG ( 35):
I/DEBUG ( 35): backtrace:
I/DEBUG ( 35): #00 pc 000018ae /data/app-lib/com.gleason.gles.na-2/libsimplena.so (Application::initWindow(android_app*)+45)
I/DEBUG ( 35): #01 pc 00001a25 /data/app-lib/com.gleason.gles.na-2/libsimplena.so (Application::handleCommand(android_app*, int)+36)
I/DEBUG ( 35): #02 pc 00001a57 /data/app-lib/com.gleason.gles.na-2/libsimplena.so
I/DEBUG ( 35): #03 pc 00001ff9 /data/app-lib/com.gleason.gles.na-2/libsimplena.so
I/DEBUG ( 35): #04 pc 00001a87 /data/app-lib/com.gleason.gles.na-2/libsimplena.so (Application::run()+42)
I/DEBUG ( 35): #05 pc 00001acf /data/app-lib/com.gleason.gles.na-2/libsimplena.so (android_main+54)
I/DEBUG ( 35): #06 pc 00001b85 /data/app-lib/com.gleason.gles.na-2/libsimplena.so
I/DEBUG ( 35): #07 pc 0000e3b8 /system/lib/libc.so (__thread_entry+72)
I/DEBUG ( 35): #08 pc 0000dab0 /system/lib/libc.so (pthread_create+160)

Using pjsua for android

Greetings to everyone!
I'm trying to compile pjsua using the following branch:
http://svn.pjsip.org/repos/pjproject/branches/projects/android/. I've
tried to do a push (adb push pjsua /data/local/) to my Android-sdk
emulator but, when I've tried to execute it via adb shell, the Android
LogCat gave me the following SIGFAULT error: where am I wrong? Thanks
in advance.
F/libc ( 464): Fatal signal 11 (SIGSEGV) at 0x000000f0 (code=1)
I/DEBUG ( 33): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 33): Build fingerprint:'generic/sdk/generic:4.0.3/MR1/237985:eng/test-keys'
I/DEBUG ( 33): pid: 464, tid: 464 >>> ./pjsua-arm-unknown-linux-androideabi <<<
I/DEBUG ( 33): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 000000f0
I/DEBUG ( 33): r0 ffffffff r1 beef7c30 r2 beef7c30 r3 ffffffff
I/DEBUG ( 33): r4 00000000 r5 00000000 r6 00000000 r7 00000000
I/DEBUG ( 33): r8 00000000 r9 00000000 10 00000000 fp 00000000
I/DEBUG ( 33): ip 4003c4b9 sp beef7c60 lr 4003c4b1 pc b000469a cpsr 00000030
I/DEBUG ( 33): d0 00000000bd6bc8e3 d1 0000000000000000
I/DEBUG ( 33): d2 0000000000000000 d3 0000000000000000
I/DEBUG ( 33): d4 0000000000000000 d5 41c8f0a46e800000
I/DEBUG ( 33): d6 3f50624dd2f1a9fc d7 c18af9670cce266f
I/DEBUG ( 33): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 33): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 33): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 33): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 33): scr 00000010
I/DEBUG ( 33):
I/DEBUG ( 33): #00 pc b000469a /system/bin/linker
I/DEBUG ( 33): #01 pc 000264ac /system/lib/libc.so (__set_errno)
I/DEBUG ( 33):
I/DEBUG ( 33): code around pc:
I/DEBUG ( 33): b0004678 95004840 44784a40 4d414b40 447b447a #H..#JxD#KAMzD{D
I/DEBUG ( 33): b0004688 682d447d f44f9103 95017140 f0009402 }D-h..O.#q......
I/DEBUG ( 33): b0004698 f8d4ff67 b10330f0 f8d44798 b17000e0 g....0...G....p.
I/DEBUG ( 33): b00046a8 10e4f8d4 f7ff2200 2000f9b5 f8d4e007 ....."..... ....
I/DEBUG ( 33): b00046b8 f04f20a8 f04230ff f8c40102 b00710a8 .O..0B.........
I/DEBUG ( 33):
I/DEBUG ( 33): code around lr:
I/DEBUG ( 33): 4003c490 f240b507 9300736c 33fff04f 466b9301 ..#.ls..O..3..kF
I/DEBUG ( 33): 4003c4a0 fd80f7ff bf00bd0e 4604b510 fe90f7ec ...........F....
I/DEBUG ( 33): 4003c4b0 f04f6004 bd1030ff 0ffff110 db02b510 .`O..0..........
I/DEBUG ( 33): 4003c4c0 f7ff4240 bd10fff1 48214603 4478b5f0 #B.......F!H..xD
I/DEBUG ( 33): 4003c4d0 b0976800 68022150 4620ac01 92154e1d .h..P!.h.. F.N..
I/DEBUG ( 33):
I/DEBUG ( 33): stack:
I/DEBUG ( 33): beef7c20 00000000
I/DEBUG ( 33): beef7c24 4003c4c7 /system/lib/libc.so
I/DEBUG ( 33): beef7c28 00000000
I/DEBUG ( 33): beef7c2c 4002f477 /system/lib/libc.so
I/DEBUG ( 33): beef7c30 b00144c4
I/DEBUG ( 33): beef7c34 00000000
I/DEBUG ( 33): beef7c38 10000000
I/DEBUG ( 33): beef7c3c 00000000
I/DEBUG ( 33): beef7c40 00000000
I/DEBUG ( 33): beef7c44 4002f49b /system/lib/libc.so
I/DEBUG ( 33): beef7c48 00000000
I/DEBUG ( 33): beef7c4c 0000c090 /data/local/pjsua-arm-unknown-linux-androideabi
I/DEBUG ( 33): beef7c50 b00144c4
I/DEBUG ( 33): beef7c54 0000c070 /data/local/pjsua-arm-unknown-linux-androideabi
I/DEBUG ( 33): beef7c58 df0027ad
I/DEBUG ( 33): beef7c5c 00000000
I/DEBUG ( 33): #01 beef7c60 00000001
I/DEBUG ( 33): beef7c64 beef7d47 [stack]
I/DEBUG ( 33): beef7c68 00000000
I/DEBUG ( 33): beef7c6c beef7d6d [stack]
I/DEBUG ( 33): beef7c70 beef7d82 [stack]
I/DEBUG ( 33): beef7c74 beef7d92 [stack]
I/DEBUG ( 33): beef7c78 beef7dba [stack]
I/DEBUG ( 33): beef7c7c beef7df7 [stack]
I/DEBUG ( 33): beef7c80 beef7e10 [stack]
I/DEBUG ( 33): beef7c84 beef7e2a [stack]
I/DEBUG ( 33): beef7c88 beef7f55 [stack]
I/DEBUG ( 33): beef7c8c beef7f68 [stack]
I/DEBUG ( 33): beef7c90 beef7f83 [stack]
I/DEBUG ( 33): beef7c94 beef7fa0 [stack]
I/DEBUG ( 33): beef7c98 beef7fb3 [stack]
I/DEBUG ( 33): beef7c9c 00000000
I/DEBUG ( 33): beef7ca0 00000010
I/DEBUG ( 33): beef7ca4 000030d7
EDIT 1: I must remark that I already know solutions such as csipsimple. Anyway, I'm interested to resolve my cross-compiling issue with Android-ndk's tools.
Why not trying to use an android device instead?
I red in the android website that the android simulator is usually not compatible with sip stacks.

Categories

Resources