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)
Related
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.
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.
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.
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.
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.