11-09-2012 06:45 AM
Any clues how to actually debug application exit code ?
If you setAutoExit(false) + request the manualExit() signal your exit handler code will be called
Because bb10 app manager has some kind of 'kill the app' if it takes too long to do stuff - like exit - by the time the debugger sortts itself out + displays stuff it appears bbOS has decided youve taken too long to exit and shot the process.
Any attempt to trace though the exit code effectively results in a kill signal in the dbgr....
Yes we can debug some of the code 'out of place' but...
11-16-2012 06:46 PM
I am not sure I understood your question exactly.
Are you just interested in knowing the exit code after the process has ended?
If so, doesn't this show up to you on the Debug view, right beside the process name? (That is, after it exits and when you have the debug point set in the debug mode/view)
On the QNX Momentics IDE (which is based on the Eclipse IDE), after the process exits, it is supposed to show the exit value right beside the name on the process (typically on the top right - where the processes are stacked).
Let us know what you think (or perhaps more information about your use question/use case).
11-17-2012 01:34 AM
Not as nice as being able to step through using the debugger, but qDebug() and watching the output with slog2info worked for me. (But then, I'm used to working on an embedded system where printf to the console is usually faster than getting gdb hooked up to a process. )
11-17-2012 04:21 AM
Rephrasing the question:
We want to save our state on exit. To do so we connect() to the exit point + run some of our code.
To ensure this code is operating correctly we like to step through the code + observe its behaviour - debugging though it as required.
The problem is that QNX and/or Eclipse dont appear to be capable of understanding each other sufficiently well to allow the above to occur. QNX decides that if you take longer than about 2 secs to exit it will terminate the process - effectively behind your back.
The debugger will stop at the breakpoint but by the time its updated the UI + allow you to start tracing though the code the 2 secs above have passed and you cant debug any further because QNX has terminated your process.
In a joined up development environment this would not happen. So the question is something like ' how do you get QNX + its debugger to understand each other properly' or is this another ide 'limitation'.
11-17-2012 04:24 AM
There are lots of ways to attack the problem, printfs (or variants being one).
Just wanted to clarify that the IDE and QNX are not actually capable of doing the job you would expect of them...