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]
-
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 modehost 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.
@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.
-
@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.
-
@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....
-
5.6.1
4.1.1 (CyanogenMod 10.1)
15
r12b
I do not use debug modehost 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.
@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. -
@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.
-
@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....
@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.
-
@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.
-
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]
@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.
-
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 ?
-
@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.
@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.
-
@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.
@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.
-
Thanks for the thorough analysis and the feedback!
