SIGSEGV after main()



  • I have created some app for Android. All works fine but when I start it from QtCreator on Android smartphone attached to PC - upon app exit I get error message in QtCreator console:

    F/libc (21589): Fatal signal 11 (SIGSEGV) at 0x01337748 (code=2), thread 21589

    I checked all memory allocations/releases but did not find any leaks. Message appears after my main() function exits. Is that known Qt for Android issue or else?

    [Edit: moved to Mobile and Embedded ~~ @Wieland]


  • Lifetime Qt Champion

    Hi,

    Please provide the followings:

    • Qt version
    • Android version
    • Android SDK version
    • Android NDK version
    • The stack trace


  • 5.6.1
    4.1.1 (CyanogenMod 10.1)
    15
    r12b
    I do not use debug mode

    host development OS - Linux Kubuntu 14

    I will see more when create similar program with SDK level 23 and run it with Android 6. But not now.


  • Moderators

    @Gourmet Since you're running linux, run valgrind on your app to find memory issues. This is almost certainly caused by a memory issue. Probably a double delete, a dangling pointer being referenced, or something like that.

    You can also run it in gdb, when it crashes, post a backtrace here.



  • @ambershark I cannot run application on Linux - it uses lots of Android SDK functionality. With Android calls turned off the application simply does not work. I tried run debug version on Android device and catch faulty place. But the stack was not informative. It stops somewhere in libc without any symbolic info. I tried walk back on stack but without success. I even did not came back to my app code.



  • @Gourmet
    The SIGSEGV probably occurs during application clean up/dispose just prior to exit.

    It may not be the solution you'd like to hear, but you might try disabling most of your code "downward", or start from a small example "upward", to see if you can find what area might be causing it. Unless someone here can offer you better advice....


  • Qt Champions 2016

    @Gourmet said in SIGSEGV after main():

    I do not use debug mode

    How do you expect to debug something if you don't use debug mode. You've given us nothing and expect us to help you, doesn't seem very possible.
    Run it through the debuger and attach the backtrace, so we have something to work with.



  • @kshegunov I said already - backtrace gives nothing. SIGSEGV occurs somewhere in libc after I finished all my job. After this I was able to return only to Qt internals, not to my code.



  • @JNBarchan said in SIGSEGV after main():

    The SIGSEGV probably occurs during application clean up/dispose just prior to exit.

    It may not be the solution you'd like to hear, but you might try disabling most of your code "downward"

    There is TOO MUCH to disable... May be there is better debug tool which can show memory usage. I almost do not use new and delete operators. There are very few direct object creations and deletions. All them are clear. Mostly I relied to Qt's parent/children relations and Qt's internal memory control.


  • Qt Champions 2016

    @Gourmet

    What about creating an default Android project and run it to see if it can crash ?
    If not, it must be in user code.

    Do you use any globals objects ?


  • Moderators

    @Gourmet Hi! Revert back to the last commit that passed all tests. Then take the next commit (the one where you broke your code) and slice it in pieces until you know what causes the crash.



  • @mrjj thanx, cap...



  • @Wieland it was too far long... About half of the year or more. LOTS of changes made. I even cannot tell when this SIGSEGV appeared. Did not notice it. Project was developed more than 1 year. And first release was made at May.

    The "revert" technique is not a solution. Best solution could be if it was possible run project under memory supervisor. But I do not know any one working in Android.


  • Moderators

    @Gourmet If it is crashing in libc, it's almost always a memory issue. You are deleting something twice, or referencing a dangling pointer. Check your destructors and clean up code and you should find your crash.

    That's the best advice I have unless you share code or backtrace or something we can work with. We're all pretty good software engineers but expecting us to solve something like this blind is pretty improbable. :)



  • Finally I found the reason of crash. And this is not about memory leakage.

    My app works in Android. It processes audio in some manner. To receive audio info it registers BroadcastReceiver in Java code called from C++ code. The BroadcastReceiver is written on Java. It catches audio events and sends audio info to native C++ code. When exiting the app unregisters BroadcastReceiver as neeed. But I have found - BroadcastReceiver remains working some time even after main native code finished. It tries call native function from code page which was already freed by OS. This causes SIGSEGV. Why this can happen? I think because unregistering function is on Java and it is executed by Dalvik virtual machine. It works in separate thread and it is much much slower than native code on C++. Main application code has time to finish while Dalvik VM processes BroadcastReceiver unregistering. I fixed problem by simple flag prohibiting BroadcastReceiver functions after call of unregistering function. SIGSEGV disappeared.


  • Lifetime Qt Champion

    Thanks for the thorough analysis and the feedback!


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.