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.
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 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.
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.
To examine PIE for main executables in Android 4.0 (ICS), I tested some sample programs in Galaxy Nexus. Results are shown below:
"-fPIE" "-pie" TYPE address
--------------------------------------------
(a) - - ET_EXE 0x00008000
(b) x - ET_EXE 0x00008000
(c) - x ET_DYN program crashed
(d) x x ET_DYN program crashed
notes: use Android NDK r7 for android-14
The results says that (a) and (b) without "-pie" is not randomized, (c) and (d) with "-pie" crash. So, I cannot enable ASLR for main executables. Crash logs are shown below:
pid: 5306, tid: 5306 >>> ./memdump <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000a020
r0 70000001 r1 b00094fc r2 00000000 r3 0000a020
r4 b000a078 r5 ffffffff r6 0000a020 r7 be933b98
r8 b0009910 r9 00000000 10 00000000 fp b0006d3b
ip 0000200f sp be933b58 lr 00001f50 pc b00041c0 cpsr 00000030
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 0000000000000000 d29 0000000000000000
d30 0000000000000000 d31 0000000000000000
scr 00000000
#00 pc b00041c0 /system/bin/linker
#01 lr 00001f50 <unknown>
code around pc:
b00041a0 6858e00a 208cf8d4 f8c41885 e00350d8
b00041b0 0895685a 50dcf8c4 e0013308 44794924
b00041c0 2d00681d af49f47f 30acf8d4 f8d4b113
b00041d0 b96110b0 7174f240 9100481e 44784a1e
b00041e0 491f4b1e 447b447a 68094479 f8d4e7b1
code around lr:
00001f30 ffffffff ffffffff ffffffff ffffffff
00001f40 ffffffff ffffffff ffffffff ffffffff
00001f50 ffffffff ffffffff ffffffff ffffffff
00001f60 ffffffff ffffffff ffffffff ffffffff
00001f70 ffffffff ffffffff ffffffff ffffffff
stack:
be933b18 00000000
be933b1c 00000000
be933b20 00000000
be933b24 00000000
be933b28 00000000
be933b2c 00000000
be933b30 00000000
be933b34 00000000
be933b38 00000000
be933b3c 00000000
be933b40 00000000
be933b44 00000000
be933b48 00000000
be933b4c 00000000
be933b50 df0027ad
be933b54 00000000
#00 be933b58 00000000
be933b5c 00000000
be933b60 b000a078
be933b64 b000a078
be933b68 be933cf1
be933b6c 00000118
be933b70 b000a078
be933b74 b000a078
be933b78 b00094f0
be933b7c 00000002
be933b80 be933b98
be933b84 b0009910
be933b88 00000000
be933b8c 00000000
be933b90 b0006d3b /system/bin/linker
be933b94 b00047ed /system/bin/linker
be933b98 00000000
be933b9c 00000000
Is not PIE for main executables supported in Android 4.0?
I have figured out the problem. Android does not support PIE for main executables. The error was due to the Android's linker (/bionic/linker/linker.cpp - link_image()). It always loads a DYNAMIC header in an executable ELF binary to a fixed address specified as the header's virtual address field, regardless of the binary TYPE (ET_EXE or ET_DYN). In the above example the specified address was 0x0000a020, so SEGV_MAPERR was occurred at the address. Moreover, the Android's linker assumes that the binary is "ET_EXE" regardress of its actual TYPE. It's a shame :-<. Thanks.
Is PIE (Position-independent executable) for main executables supported in Android 4.0 (ICS)?
PIE support was added in Android 4.1, not 4.0. See Security Enhancements in Android 1.5 through 4.1.
When I try to run PIE code on Android 4.0 or below, I get a segfault in /system/bin/linker. Your mileage may vary.