Debugging stack corruption detected: aborted

[pps]

I have a library (a voice codec) that produces that stack corruption error on android. I'm having hard time figuring out value of that stack protection BS if it gives me no clue how to debug it. So, I'd like to ask for possible techniques that I could use to identify and fix the issue.
Perhaps, I could go to functions that allocate lots of stuff on stack and add padding to structures and then re-run it again to see if stack corruption error disappears, but this is not a very practical approach, since the library is quite big. Another possible approach: manually trigger stack checks after each function and abort/assert asap from inside my app and generate usable backrace to see where it aborted. Right now I get totally dumb useless crash with extremely valuable message:

F//system/bin/app_process(19796): stack corruption detected: aborted

There is lots of info on the web, but everything is useless and doesn't even mention what should be done for detection of the code that corrupted the stack.
So, my questions is: what should be done to actually fix stack corruption? I use latest r8d NDK and I don't have any good debugging tools for android (and I obviously not going waste a day of my life trying to build valgrind for android), my main dev platformt is windows/VS2008.... so, please advise how do u fix that kind of problems in the stone age of the NDK development ;)

thanks.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/a-JUXPj2XrwJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[pps]

Just to add more info. If I build the codec library with -fstack-protector-strong or -fstack-protector-all it crashes the app that uses the library. If I build it with -fno-stack-protector then it runs fine (even thought the main app is compiled with stack protection).

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/InaSv9DRJHMJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[dtx0]

gcc has "-fstack-check" as a general option and also "-mapcs-stack-check" and "-mno-apcs-stack-check" for ARM. Did you try those out? 

Android, likewise, has logging facilities in "/android/log.h" and can be linked with the "-llog" switch.

There's no "magic pill" to solving these problems, but there's one product I know of out there that comes close: Hex-Rays IDA (note: I'm not advertising this product by any means; also, it's very-very expensive). 

My best advice? Post the code and maybe I or someone else can help you find the problem. Cheers.

On Friday, January 4, 2013 8:10:01 PM UTC-8, pps wrote:

Just to add more info. If I build the codec library with -fstack-protector-strong or -fstack-protector-all it crashes the app that uses the library. If I build it with -fno-stack-protector then it runs fine (even thought the main app is compiled with stack protection).

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/TfKBM_qw8kIJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[a1]

There is lots of info on the web, but everything is useless and doesn't even mention what should be done for detection of the code that corrupted the stack.
So, my questions is: what should be done to actually fix stack corruption? I use latest r8d NDK and I don't have any good debugging tools for android (and I obviously not going waste a day of my life trying to build valgrind for android), my main dev platformt is windows/VS2008.... so, please advise how do u fix that kind of problems in the stone age of the NDK development ;)

 

Now that's really smart, why "waste" a day with valgrind (which is rather a few hours) which not only will allow to locate this kind of bug in no time but will also help you debug other problems. Anyway if you decide to "waste" a day I can provide a few pointers since I recently setup valgrind for android (and I also mainly develop in vs). 

First of all you need linux box, personally I've used virtualbox to install ubuntu, current valgrind version already has support for android so there is no hacking required. I used virtualized x86 system image as test machine (so I build x86 version of valgrind).

Now a bit of trickery was required to run this setup, there is a readme in valgrind (http://valgrind.org/docs/manual/dist.readme-android.html) which cover building and installing. To run application with valgrind simply call following: adb shell setprop wrap.your.package.name "logwrapper /data/local/Inst/bin/valgrind" (you may add additional parameters there if you like).

Few issues wort mentioning: first of all make sure that valgrind has +x attribute, also there are several tutorials on web that suggest using shell script to wrap application process - I've never were able to setup that that's why I use valgrind directly in setprop, last thing: remember to kill your application process after setting wrap.* property.

Getting exact location of detected error is also a bit tricky, since binaries in APK are stripped valgrind will report only symbols (function names) and addresses, no line numbers, you can of course use addr2line but you need base address of your .so extracted from /proc/<pid>/smaps. 

BTW if someone know how to disable stripping in ndk-build (if possible) that'd great, I tried to do so but ndk-build system is far too complicated for my lowly make skills.

--

Bart

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/oh80F8eNLpQJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[dtx0]

Here's a simple guide to disabling the strip feature: <http://permadi.com/blog/2011/09/setting-up-android-jni-projects-in-windows-eclipse-and-sequoyah/>. Enjoy.

On Saturday, January 5, 2013 1:21:29 AM UTC-8, a1 wrote:

There is lots of info on the web, but everything is useless and doesn't even mention what should be done for detection of the code that corrupted the stack.
So, my questions is: what should be done to actually fix stack corruption? I use latest r8d NDK and I don't have any good debugging tools for android (and I obviously not going waste a day of my life trying to build valgrind for android), my main dev platformt is windows/VS2008.... so, please advise how do u fix that kind of problems in the stone age of the NDK development ;)

 

Now that's really smart, why "waste" a day with valgrind (which is rather a few hours) which not only will allow to locate this kind of bug in no time but will also help you debug other problems. Anyway if you decide to "waste" a day I can provide a few pointers since I recently setup valgrind for android (and I also mainly develop in vs). 

First of all you need linux box, personally I've used virtualbox to install ubuntu, current valgrind version already has support for android so there is no hacking required. I used virtualized x86 system image as test machine (so I build x86 version of valgrind).

Now a bit of trickery was required to run this setup, there is a readme in valgrind (http://valgrind.org/docs/manual/dist.readme-android.html) which cover building and installing. To run application with valgrind simply call following: adb shell setprop wrap.your.package.name "logwrapper /data/local/Inst/bin/valgrind" (you may add additional parameters there if you like).

Few issues wort mentioning: first of all make sure that valgrind has +x attribute, also there are several tutorials on web that suggest using shell script to wrap application process - I've never were able to setup that that's why I use valgrind directly in setprop, last thing: remember to kill your application process after setting wrap.* property.

Getting exact location of detected error is also a bit tricky, since binaries in APK are stripped valgrind will report only symbols (function names) and addresses, no line numbers, you can of course use addr2line but you need base address of your .so extracted from /proc/<pid>/smaps. 

BTW if someone know how to disable stripping in ndk-build (if possible) that'd great, I tried to do so but ndk-build system is far too complicated for my lowly make skills.

--

Bart

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/4M2cMrvImhwJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[pps]

I agree, valgrind is very useful and I was thinking to get it working with andrdoid, but the page that describes how to get it running with android is far too long to to even read it (from one of mozilla/webkit developers who started valgrind porting to android). It looked like I need special build of android for valgrind, that is a big turn off for me. I have like 100 phones to run my builds on and I need tools that work well everywhere. I really miss debugging with VS on windows mobile phones, all that linux/gcc/gdb seems too far inferior to MS tools even though I'm full time on android NDK for the last couple of years. Basically, our android development/bugfixing totally relies on windows port and development tools that are available for windows, but obviously some parts of code simply cannot be tested/debugged on windows port.
So, you say that you used valgrind on android. Is it a standalone valgrind apk/executable that can be installed/copied to an android-arm phone and using some scripts I can get it running? I don't need to dance 10 hour rituals to get it working. The thing is that so far I use visual studio and windows port of our stuff for testing and debugging (thanks microsoft for good tools :), and I only need android specific tools quite rarely, that's why I I'm saying that I don't want to waste 10 hours just to get it barely working. At the same time I agree, it's probably the only tool that I think is better than similar tools available on windows.

to "disable" stripping in ndk, you can manually copy unstripped libs from obj\local\armeabi to libs. I use stripped libs, but then I run addr2line against unstripped ones to get backtraces.


On Saturday, January 5, 2013 4:21:29 AM UTC-5, a1 wrote:

There is lots of info on the web, but everything is useless and doesn't even mention what should be done for detection of the code that corrupted the stack.
So, my questions is: what should be done to actually fix stack corruption? I use latest r8d NDK and I don't have any good debugging tools for android (and I obviously not going waste a day of my life trying to build valgrind for android), my main dev platformt is windows/VS2008.... so, please advise how do u fix that kind of problems in the stone age of the NDK development ;)

 

Now that's really smart, why "waste" a day with valgrind (which is rather a few hours) which not only will allow to locate this kind of bug in no time but will also help you debug other problems. Anyway if you decide to "waste" a day I can provide a few pointers since I recently setup valgrind for android (and I also mainly develop in vs). 

First of all you need linux box, personally I've used virtualbox to install ubuntu, current valgrind version already has support for android so there is no hacking required. I used virtualized x86 system image as test machine (so I build x86 version of valgrind).

Now a bit of trickery was required to run this setup, there is a readme in valgrind (http://valgrind.org/docs/manual/dist.readme-android.html) which cover building and installing. To run application with valgrind simply call following: adb shell setprop wrap.your.package.name "logwrapper /data/local/Inst/bin/valgrind" (you may add additional parameters there if you like).

Few issues wort mentioning: first of all make sure that valgrind has +x attribute, also there are several tutorials on web that suggest using shell script to wrap application process - I've never were able to setup that that's why I use valgrind directly in setprop, last thing: remember to kill your application process after setting wrap.* property.

Getting exact location of detected error is also a bit tricky, since binaries in APK are stripped valgrind will report only symbols (function names) and addresses, no line numbers, you can of course use addr2line but you need base address of your .so extracted from /proc/<pid>/smaps. 

BTW if someone know how to disable stripping in ndk-build (if possible) that'd great, I tried to do so but ndk-build system is far too complicated for my lowly make skills.

--

Bart

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/B9XDQE9y_D4J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Ray Donnelly]

I've got some interest in valgrind for Android but haven't looked into it much.

This page might prove helpful. They don't build a custom ROM but still
get some value from valgrind:

https://staktrace.com/spout/entry.php?id=762

Ray.

On Sat, Jan 5, 2013 at 11:15 PM, pps <[hidden email]> wrote:

> I agree, valgrind is very useful and I was thinking to get it working with
> andrdoid, but the page that describes how to get it running with android is
> far too long to to even read it (from one of mozilla/webkit developers who
> started valgrind porting to android). It looked like I need special build of
> android for valgrind, that is a big turn off for me. I have like 100 phones
> to run my builds on and I need tools that work well everywhere. I really
> miss debugging with VS on windows mobile phones, all that linux/gcc/gdb
> seems too far inferior to MS tools even though I'm full time on android NDK
> for the last couple of years. Basically, our android development/bugfixing
> totally relies on windows port and development tools that are available for
> windows, but obviously some parts of code simply cannot be tested/debugged
> on windows port.
> So, you say that you used valgrind on android. Is it a standalone valgrind
> apk/executable that can be installed/copied to an android-arm phone and
> using some scripts I can get it running? I don't need to dance 10 hour
> rituals to get it working. The thing is that so far I use visual studio and
> windows port of our stuff for testing and debugging (thanks microsoft for
> good tools :), and I only need android specific tools quite rarely, that's
> why I I'm saying that I don't want to waste 10 hours just to get it barely
> working. At the same time I agree, it's probably the only tool that I think
> is better than similar tools available on windows.
>
> to "disable" stripping in ndk, you can manually copy unstripped libs from
> obj\local\armeabi to libs. I use stripped libs, but then I run addr2line
> against unstripped ones to get backtraces.
>
>
>
> On Saturday, January 5, 2013 4:21:29 AM UTC-5, a1 wrote:
>>
>>
>>> There is lots of info on the web, but everything is useless and doesn't
>>> even mention what should be done for detection of the code that corrupted
>>> the stack.
>>> So, my questions is: what should be done to actually fix stack
>>> corruption? I use latest r8d NDK and I don't have any good debugging tools
>>> for android (and I obviously not going waste a day of my life trying to
>>> build valgrind for android), my main dev platformt is windows/VS2008.... so,
>>> please advise how do u fix that kind of problems in the stone age of the NDK
>>> development ;)
>>
>>
>> Now that's really smart, why "waste" a day with valgrind (which is rather
>> a few hours) which not only will allow to locate this kind of bug in no time
>> but will also help you debug other problems. Anyway if you decide to "waste"
>> a day I can provide a few pointers since I recently setup valgrind for
>> android (and I also mainly develop in vs).
>> First of all you need linux box, personally I've used virtualbox to
>> install ubuntu, current valgrind version already has support for android so
>> there is no hacking required. I used virtualized x86 system image as test
>> machine (so I build x86 version of valgrind).
>>
>> Now a bit of trickery was required to run this setup, there is a readme in
>> valgrind (http://valgrind.org/docs/manual/dist.readme-android.html) which
>> cover building and installing. To run application with valgrind simply call
>> following: adb shell setprop wrap.your.package.name "logwrapper
>> /data/local/Inst/bin/valgrind" (you may add additional parameters there if
>> you like).
>> Few issues wort mentioning: first of all make sure that valgrind has +x
>> attribute, also there are several tutorials on web that suggest using shell
>> script to wrap application process - I've never were able to setup that
>> that's why I use valgrind directly in setprop, last thing: remember to kill
>> your application process after setting wrap.* property.
>>
>> Getting exact location of detected error is also a bit tricky, since
>> binaries in APK are stripped valgrind will report only symbols (function
>> names) and addresses, no line numbers, you can of course use addr2line but
>> you need base address of your .so extracted from /proc/<pid>/smaps.
>> BTW if someone know how to disable stripping in ndk-build (if possible)
>> that'd great, I tried to do so but ndk-build system is far too complicated
>> for my lowly make skills.
>>
>> --
>> Bart
>
> --
> You received this message because you are subscribed to the Google Groups
> "android-ndk" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/android-ndk/-/B9XDQE9y_D4J.
>
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/android-ndk?hl=en.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[a1]

I agree, valgrind is very useful and I was thinking to get it working with andrdoid, but the page that describes how to get it running with android is far too long to to even read it (from one of mozilla/webkit developers who started valgrind porting to android).

That's why I linked to detailed build instruction for valgrind for android, out of box it support xoom, nexus s and android emulator, I personally use haxm x86 emulator. No need to build custom system image.

 

So, you say that you used valgrind on android. Is it a standalone valgrind apk/executable that can be installed/copied to an android-arm phone and using some scripts I can get it running?

Yes, whole setup indeed took me around 12h (including virtualbox setup and so on).

 

to "disable" stripping in ndk, you can manually copy unstripped libs from obj\local\armeabi to libs. I use stripped libs, but then I run addr2line against unstripped ones to get backtraces.

I didn't think about that :) I'd of course prefer build system modification but it'll probably work just fine (as I said its not required but with unstripped so you'll get line numbers in valgrind traces).

--

Bart

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/2BuVHHZqX_gJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.