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.
Related
Built an app using Appcelerator and seem to be getting this crash report a lot.
It can happen from anywhere from 10 seconds to 5 minutes and i cant seem to see a pattern which makes me think it may be a memory issue.
could someone please help point me in the right direction of what to do / even look for?
Many thanks in advance.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'lge/awifi_open_eu/awifi:4.4.2/KOT49I.V50020f/.1442277816:user/release-keys'
Revision: '11'
pid: 17156, tid: 17160, name: GC >>> com.adzmedia.cureit <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 85443c34
r0 42a24343 r1 85443c30 r2 42a24340 r3 42a1f8f8
r4 5ba1dad4 r5 420b7008 r6 5ba1dc18 r7 42a242e8
r8 00000000 r9 42a1f950 sl 416d4adc fp 80000000
ip 00000003 sp 5ba1da20 lr 4174c5f5 pc 4174c5e2 cpsr 900f0030
d0 0000000000000000 d1 0000000000000000
d2 0000000000000000 d3 0000000000000000
d4 0000000000000000 d5 0000000000000000
d6 0000000000000000 d7 0000000000000000
d8 0000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
d16 0000000000000000 d17 0000000000000000
d18 0000000000000000 d19 0000000000000000
d20 0000000000000000 d21 0000000000000000
d22 0000000000000000 d23 0000000000000000
d24 0000000000000000 d25 0000000000000000
d26 0000000000000000 d27 0000000000000000
d28 0100010001000100 d29 0100010001000100
d30 0000000000000000 d31 0000000000000000
scr 20000010
backtrace:
#00 pc 000755e2 /system/lib/libdvm.so (mspace_bulk_free+89)
#01 pc 000764df /system/lib/libdvm.so (dvmHeapSourceFreeList(unsigned int, void**)+70)
#02 pc 0003a0ac /system/lib/libdvm.so
#03 pc 0002bd40 /system/lib/libdvm.so (dvmHeapBitmapSweepWalk(HeapBitmap const*, HeapBitmap const*, unsigned int, unsigned int, void (*)(unsigned int, void**, void*), void*)+176)
#04 pc 0003ae4c /system/lib/libdvm.so (dvmHeapSweepUnmarkedObjects(bool, bool, unsigned int*, unsigned int*)+284)
#05 pc 0002c268 /system/lib/libdvm.so (dvmCollectGarbageInternal(GcSpec const*)+452)
#06 pc 000759cd /system/lib/libdvm.so
#07 pc 00057b75 /system/lib/libdvm.so
#08 pc 0000d2e8 /system/lib/libc.so (__thread_entry+72)
#09 pc 0000d480 /system/lib/libc.so (pthread_create+240)
code around pc:
4174c5c0 454f0908 f8dcd113 f0007004 f0400001
4174c5d0 f0270c02 18ba0707 ea4c1889 f8430002
4174c5e0 684a0c04 0001f042 60236048 4628e002
4174c5f0 fbf6f7fd d1d042b4 69eb68e9 d9134299
4174c600 21004628 ff24f7fd 42b4e00e 0207f020
4174c610 0c02eb01 e7ead1d2 22004805 44784905
4174c620 f7fd4479 e7e7fbc7 e8bd2000 bf0083f8
4174c630 0003bbd9 000441e8 43f8e92d 69874688
4174c640 2f004691 f500d038 682a75e0 0308f102
4174c650 0007f013 425cd002 0007f004 e0171814
4174c660 f1041f02 e0060008 bf9428f8 0010f104
4174c670 0020f104 42b02200 4631d202 47c0464b
4174c680 d10442bc 2d0068ad e8bdd1df 463483f8
4174c690 428c6829 686ad3f6 0c02eb01 d2f14564
4174c6a0 2b076863 f003d0ee f0230103 29010007
4174c6b0 0600eb04 e7d7d1d4 83f8e8bd bec8f7fd
code around lr:
4174c5d4 18ba0707 ea4c1889 f8430002 684a0c04
4174c5e4 0001f042 60236048 4628e002 fbf6f7fd
4174c5f4 d1d042b4 69eb68e9 d9134299 21004628
4174c604 ff24f7fd 42b4e00e 0207f020 0c02eb01
4174c614 e7ead1d2 22004805 44784905 f7fd4479
4174c624 e7e7fbc7 e8bd2000 bf0083f8 0003bbd9
4174c634 000441e8 43f8e92d 69874688 2f004691
4174c644 f500d038 682a75e0 0308f102 0007f013
4174c654 425cd002 0007f004 e0171814 f1041f02
4174c664 e0060008 bf9428f8 0010f104 0020f104
4174c674 42b02200 4631d202 47c0464b d10442bc
4174c684 2d0068ad e8bdd1df 463483f8 428c6829
4174c694 686ad3f6 0c02eb01 d2f14564 2b076863
4174c6a4 f003d0ee f0230103 29010007 0600eb04
4174c6b4 e7d7d1d4 83f8e8bd bec8f7fd e92d4b2d
4174c6c4 447b41f0 f8df4605 681880b0 b90844f8
A SIGSEV exception is a Segmentation Fault. You try to access something that has never been there or more likely garbage collected. This is hard to debug. This question explains how you can trace this back to the exact Titanium SDK method, but then still the question is what JavaScript code if you use the same Titanium API on multiple occasions. It might be easier to see what you do (or automatically have done) right before it crashes and comment out pieces of code to see what causes it. Unfortunately since you say it happens at random times that still might be a challenge.
I'm using tess-two without problems, but when I call the TessBaseAPI.end() the application crashes. This log message is displayed.
06-26 09:06:18.065 2347-14702/? I/ActivityManager﹕ Killing proc 14146:br.com.nglauber.app.ocr/u0a10163: force stop br.com.nglauber.app.ocr
06-26 09:06:18.065 2347-14702/? W/ActivityManager﹕ Force removing ActivityRecord{431661d8 u0 br.com.nglauber.app.ocr/br.com.nglauber.app.payoff.PayoffActivity}: app died, no saved state
06-26 09:06:18.230 2347-2461/? D/CrashAnrDetector﹕ Build: samsung/m0ub/m0:4.3/JSS15J/I9300UBUGNL1:user/release-keys
Hardware: smdk4x12
Revision: 12
Bootloader: I9300UBUGNL1
Radio: unknown
Kernel: Linux version 3.0.31-2812098 (se.infra#SWDA2610) (gcc version 4.4.3 (GCC) ) #1 SMP PREEMPT Tue Dec 16 22:20:53 KST 2014
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/m0ub/m0:4.3/JSS15J/I9300UBUGNL1:user/release-keys'
Revision: '12'
pid: 14146, tid: 14663, name: Thread-1376 >>> br.com.nglauber.app.ocr <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 000000a8
r0 5ee9d660 r1 00000020 r2 00000001 r3 00000000
r4 0000006f r5 64ed19c8 r6 5ee9ce90 r7 60cea2f8
r8 60bafa48 r9 64f3c868 sl 00000018 fp 000000fe
ip 60eac448 sp 64362390 lr 607a9da7 pc 607a9d9e cpsr 88000030
d0 01a56e1fc2f8f359 d1 3f11155ab300621e
d2 3f1114d75eadfb55 d3 3fe188c800000000
d4 407f400000000000 d5 3f71c92245382f5d
d6 3f71c92245382f5d d7 000000fe3f7ee36e
d8 000000003f800000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
d16 403ec1e0872ff28d d17 bfa2b4442c6a6c2f
d18 3e64852cd8c08bf7 d19 3fc4c82f9669a9cd
d20 3ca1a62633145c07 d21 3fc249249976c1af
d22 bfbc71c70ac3a12e d23 3fb745cdd03b7830
d24 bfb3b0f2b9082f3f d25 3fb10d66a8fbcae1
d26 bfadde2d5edd7fa8 d27 3fa97b4b29cee400
d28 3f90ad3ae322da11 d29 3f29a0080575b857
d30 3fd555555b323d4d d31 bfc99999a2b7aa58
scr 68000093
backtrace:
#00 pc 000bfd9e /data/app-lib/br.com.nglauber.app.ocr-1/libtess.so (tesseract::Classify::ComputeCharNormArrays(FEATURE_STRUCT*, INT_TEMPLATES_STRUCT*, unsigned char*, unsigned char*)+73)
#01 pc 000c0c7f /data/app-lib/br.com.nglauber.app.ocr-1/libtess.so (tesseract::Classify::CharNormTrainingSample(bool, int, tesseract::TrainingSample const&, GenericVector<tesseract::UnicharRating>*)+210)
stack:
64362350 00000000
64362354 0000006e
64362358 5ee9ce90
6436235c 64f3c868
64362360 60bafa48
64362364 000000ff
64362368 64f3c868
6436236c 607b154f /data/app-lib/br.com.nglauber.app.ocr-1/libtess.so (tesseract::Classify::ComputeIntCharNormArray(FEATURE_STRUCT const&, unsigned char*)+54)
64362370 3f800000
64362374 00000000
64362378 5ee9d660
6436237c 0000006e
64362380 00000001
64362384 0000006e
64362388 df0027ad
6436238c 00000000
#00 64362390 64f3c868
64362394 64fb8600
64362398 5ee9ce90
6436239c 5c43be18
643623a0 64f3c868
643623a4 64ed19c8
643623a8 00000056
643623ac 00000000
643623b0 60bafa48
643623b4 607aac83 /data/app-lib/br.com.nglauber.app.ocr-1/libtess.so (tesseract::Classify::CharNormTrainingSample(bool, int, tesseract::TrainingSample const&, GenericVector<tesseract::UnicharRating>*)+214)
#01 643623b8 64ed19c8
643623bc 607b2f51 /data/app-lib/br.com.nglauber.app.ocr-1/libtess.so (tesseract::Classify::ExtractFeatures(TBLOB const&, bool, GenericVector<INT_FEATURE_STRUCT>*, GenericVector<INT_FEATURE_STRUCT>*, INT_FX_RESULT_STRUCT*, GenericVector<int>*)+276)
643623c0 643624ac
643623c4 64f863c0
643623c8 00000010
643623cc 00000004
643623d0 4018c03c
643623d4 00000004
643623d8 6337a750
643623dc ffffffff
643623e0 643623e8
643623e4 608e0c14 /data/app-lib/br.com.nglauber.app.ocr-1/libtess.so
643623e8 ff40ff40
643623ec 00c000c0
643623f0 00000158
643623f4 00000010
memory near r0:
5ee9d640 00000001 00000000 00000000 00000000
5ee9d650 00000000 00000000 00000000 5eea89e0
5ee9d660 00000000 00000000 00000000 00000000
5ee9d670 00000000 5eea8c20 608919fe 60891a10
5ee9d680 00000000 00000000 0000000
06-26 09:06:18.230 2347-2461/? D/CrashAnrDetector﹕ processName:br.com.nglauber.app.ocr
06-26 09:06:18.230 2347-2461/? D/CrashAnrDetector﹕ broadcastEvent : br.com.nglauber.app.ocr SYSTEM_TOMBSTONE
More details:
- It's happening in normal app use and during my tests (using Espresso + Spoon)
- I'm using Samsung GT-I9300 running Android 4.3, but I think is happening in other devices too.
- Yes, I'm using the default construtor. TessBaseAPI baseApi = new TessBaseAPI();
- I declared baseApi as field in my class, and call setImage and getUTF8Text several times in a different Thread (problem?). When the Activity is destroyed, I call the end() method.
- I'm using the eng.traineddata available here: https://github.com/tesseract-ocr/tessdata.
Any idea? Is there a good way to release the memory allocated by tess-two?
Calling end() is the correct way to release the memory allocated by tess-two, and running the OCR on a separate thread will help to keep your app responsive.
This crash is apparently happening due to calling end() while recognition is still in progress on the other thread.
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.
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" />