Using malloc / free in android - 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.

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.

Android app_process segmentation fault trying to run own app

I am trying to run a java app/script from adb shell on an unrooted device without installing it as a package first. I tried to use app_process the same way as e.g. am is run - however I get a segmentation fault. I am wondering if this is possible at all considering security.
This is the code:
public class example {
public static void main(String[] args) {
System.out.println("Hello world");
}
}
This works fine in Windows:
$ javac example.java
$ java example
Hello world
$ java -jar example.jar
Hello world
I created an example.jar file with a manifest and the class inside (I tried with and without the class as am does not use an executable jar) and uploaded both to /sdcard/. Now in the shell (via adb) I do the following, which just produces Segmentation Fault on the console:
base=/system && export CLASSPATH=/sdcard/example.jar && app_process $base/bin example
Here is what logcat says:
D/AndroidRuntime(14289): >>>>>> AndroidRuntime START com.android.internal.os.RuntimeInit <<<<<<
D/AndroidRuntime(14289): CheckJNI is OFF
D/AndroidRuntime(14289): setted country_code = UK
D/AndroidRuntime(14289): setted countryiso_code = GB
D/AndroidRuntime(14289): setted sales_code = TMU
D/AndroidRuntime(14289): readGMSProperty: start
D/AndroidRuntime(14289): readGMSProperty: already setted!!
D/AndroidRuntime(14289): readGMSProperty: end
D/AndroidRuntime(14289): addProductProperty: start
D/dalvikvm(14289): Trying to load lib libjavacore.so 0x0
D/dalvikvm(14289): Added shared lib libjavacore.so 0x0
D/dalvikvm(14289): Trying to load lib libnativehelper.so 0x0
D/dalvikvm(14289): Added shared lib libnativehelper.so 0x0
I/dalvikvm(14289): Zip is good, but no classes.dex inside, and no valid .odex file in the same directory
E/appproc (14289): ERROR: could not find class 'example'
E/JNIHelp (14289): Native registration unable to find class 'android/debug/JNITest', aborting
F/libc (14289): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 14289 (app_process)
I/DEBUG ( 1835): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 1835): Build fingerprint: 'samsung/GT-I9100/GT-I9100:4.1.2/JZO54K/I9100XWLSY:user/release-keys'
I/DEBUG ( 1835): pid: 14289, tid: 14289, name: app_process >>> app_process <<<
I/DEBUG ( 1835): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
I/DEBUG ( 1835): r0 00000027 r1 deadbaad r2 40141b0c r3 00000000
I/DEBUG ( 1835): r4 00000000 r5 bec3690c r6 402a8ea8 r7 00000002
I/DEBUG ( 1835): r8 402b1828 r9 400ddfc1 sl 400ddf94 fp 400ddfca
I/DEBUG ( 1835): ip 40181fe0 sp bec36908 lr 40113c65 pc 401102fe cpsr 60000030
I/DEBUG ( 1835): d0 0000000000000004 d1 0000000000000000
I/DEBUG ( 1835): d2 0000000000000000 d3 0000000000000000
I/DEBUG ( 1835): d4 0000000000000000 d5 0000000000000000
I/DEBUG ( 1835): d6 0000000000000000 d7 83cc7a9b00000000
I/DEBUG ( 1835): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 1835): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 1835): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 1835): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 1835): d16 0000000000000017 d17 0000000000000000
I/DEBUG ( 1835): d18 4172e2b5a0000000 d19 0000000000000000
I/DEBUG ( 1835): d20 0000000000000000 d21 0000000000000000
I/DEBUG ( 1835): d22 0000000000000000 d23 0000000000000000
I/DEBUG ( 1835): d24 0000000000000000 d25 0000000000000000
I/DEBUG ( 1835): d26 0000000000000000 d27 0000000000000000
I/DEBUG ( 1835): d28 0000000000000000 d29 0000000000000000
I/DEBUG ( 1835): d30 0000000000000000 d31 0000000000000000
I/DEBUG ( 1835): scr 60000010
I/DEBUG ( 1835):
I/DEBUG ( 1835): backtrace:
I/DEBUG ( 1835): #00 pc 000182fe /system/lib/libc.so
I/DEBUG ( 1835): #01 pc 0000dc04 /system/lib/libc.so (abort+4)
I/DEBUG ( 1835): #02 pc 00000955 /system/lib/libnativehelper.so (jniRegisterNativeMethods+72)
I/DEBUG ( 1835): #03 pc 0004d4a7 /system/lib/libandroid_runtime.so (android::AndroidRuntime::startReg(_JNIEnv*)+34)
I/DEBUG ( 1835): #04 pc 0004d5a5 /system/lib/libandroid_runtime.so (android::AndroidRuntime::start(char const*, char const*)+200)
I/DEBUG ( 1835): #05 pc 00000dcf /system/bin/app_process
I/DEBUG ( 1835):
Is there any way to get this work? If yes what am I missing - I can see the ERROR in the log so the class is probably in the wrong place, by can I get it working from the .jar file, or from a location where I can put the class on an unrooted device?
My goal is to run a Java app/script (similar to how you can run am, pm, dumpsys) in the background using adb, doing some things, while the device runs other things as usual from the GUI, so I don't want to install it as a package / run an intent.

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 ndk-stack to read crash logs

I'm using cocos2d-x v2.1.4 and I have this crash log from logcat:
I/DEBUG ( 6575): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 6575): Build fingerprint: 'acer/a500_ww_gen1/picasso:4.0.3/IML74K/1333032611:user/release-keys'
I/DEBUG ( 6575): pid: 6680, tid: 6680 >>> com.xxxxx.xxxxx <<<
I/DEBUG ( 6575): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 5bd10d1f
I/DEBUG ( 6575): r0 0000006e r1 5ceda8ec r2 00000000 r3 5bd10d1f
I/DEBUG ( 6575): r4 00000000 r5 5bb4dfc1 r6 5bd13c38 r7 5ceda8ec
I/DEBUG ( 6575): r8 00007530 r9 00000000 10 00000000 fp 5bd13c38
I/DEBUG ( 6575): ip 5bd76e4c sp 5ced9948 lr 5bb4e179 pc 5bb4dfce cpsr 00000030
I/DEBUG ( 6575): d0 0000000000000000 d1 0000000000000000
I/DEBUG ( 6575): d2 0000000000000000 d3 000000003f000000
I/DEBUG ( 6575): d4 0000000000000000 d5 0000000000000000
I/DEBUG ( 6575): d6 0000000000000000 d7 0000000000000000
I/DEBUG ( 6575): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 6575): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 6575): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 6575): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 6575): scr 80000012
I/DEBUG ( 6575):
I/DEBUG ( 6575): #00 pc 0032ffce /data/data/com.xxxxx.xxxxx/lib/libgame.so
I/DEBUG ( 6575): #01 pc 00330176 /data/data/com.xxxxx.xxxxx/lib/libgame.so
I/DEBUG ( 6575): #02 pc 00330f68 /data/data/com.xxxxx.xxxxx/lib/libgame.so (curl_mvsnprintf)
I/DEBUG ( 6575): #03 pc 00323e2c /data/data/com.xxxxx.xxxxx/lib/libgame.so (Curl_failf)
I/DEBUG ( 6575): #04 pc 0031d39e /data/data/com.xxxxx.xxxxx/lib/libgame.so (Curl_resolv_timeout)
I/DEBUG ( 6575): #05 pc 00329ea2 /data/data/com.xxxxx.xxxxx/lib/libgame.so (Curl_connect)
I can tell from this log that it was caused by a cURL method not properly finishing or something but I want to know which function causes the crash. I tried using ndk-stack but I am getting this result:
********** Crash dump: **********
Build fingerprint: 'acer/a500_ww_gen1/picasso:4.0.3/IML74K/1333032611:user/release-keys'
pid: 6498, tid: 6498 >>> com.xxxxx.xxxxx <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 5bb71d1f
Stack frame #00 pc 0032ffce /data/data/com.xxxxx.xxxxx/lib/libgame.so: Unable to locate routine information for address 32ffce in module /Users/xxxxx/Desktop/xxxxx/_projects/xxxxx/xxxxx/proj.android/obj/local/armeabi/libgame.so
Stack frame #01 pc 00330176 /data/data/com.xxxxx.xxxxx/lib/libgame.so: Unable to locate routine information for address 330176 in module /Users/xxxxx/Desktop/xxxxx/_projects/xxxxx/xxxxx/proj.android/obj/local/armeabi/libgame.so
Stack frame #02 pc 00330f68 /data/data/com.xxxxx.xxxxx/lib/libgame.so (curl_mvsnprintf): Unable to locate routine information for address 330f68 in module /Users/xxxxx/Desktop/xxxxx/_projects/xxxxx/xxxxx/proj.android/obj/local/armeabi/libgame.so
Stack frame #03 pc 00323e2c /data/data/com.xxxxx.xxxxx/lib/libgame.so (Curl_failf): Unable to locate routine information for address 323e2c in module /Users/xxxxx/Desktop/xxxxx/_projects/xxxxx/xxxxx/proj.android/obj/local/armeabi/libgame.so
Stack frame #04 pc 0031d39e /data/data/com.xxxxx.xxxxx/lib/libgame.so (Curl_resolv_timeout): Unable to locate routine information for address 31d39e in module /Users/xxxxx/Desktop/xxxxx/_projects/xxxxx/xxxxx/proj.android/obj/local/armeabi/libgame.so
Stack frame #05 pc 00329ea2 /data/data/com.xxxxx.xxxxx/lib/libgame.so (Curl_connect): Unable to locate routine information for address 329ea2 in module /Users/xxxxx/Desktop/xxxxx/_projects/xxxxx/xxxxx/proj.android/obj/local/armeabi/libgame.so
Is there a way to get more meaningful information from the stack trace?
Or is it because I'm using libcurl which was compiled as static library, and ndk-stack wasn't able to find information about it?
you can use VisualGDB , using VisualGDB you can debug your native code in visual studio,
you have to install the VisualGDB plugin in visual studio, then you can import your exsisting cocos2d-x Android Eclipse project to visual studio. You can check the following link
http://visualgdb.com/tutorials/android/
I have configured my cocos2d android project to visual studio with the help of VisualGDB, let me know if you face any issue.

libspotify.so.12.1.51 segfaults on 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" />

Categories

Resources