Hello there, Could somebody please give me a hint about how to get stack trace in Symbian. I'm experiencing KERN-EXEC 0 panic, but cannot locate it's origin. I've seen other SO questions about this, like this, but there's only a description of how to solve this problem on emulator. But my program deals with Wi-Fi and have to be run on device. Maybe there's some way of having the stack traced or break at panic?
+1
A:
KERN-EXEC 0 means you are using a bad handle, so check all your RClasses.
You can't debug system crashes on a production device. If you can build a custom ROM for your device then you can include the kernel extensions "exmondebug.dll" and "exmoncommon.dll", now when the device crashes it will drop you into the debug monitor. From here you can enter the password "replacement" dump out all the system stacks etc.. (type help for info).
If you don't have access to developer hardware, you can run custom Symbian^2 and Symbian^3 ROM images on QEMU with the Syborg baseport, I don't think it has wifi support but there is an Ethernet driver.
George Norton
2010-09-08 15:53:58
Thanks for your answer. I believe that in most cases it is a good way: take the OS, developers hardware or emulator and run it with options you need. But, unfortunately, it is impossible for me for several reasons: 1. My code do not compile on Symbian^3 (usage of some deprecated APIs). 2. My problem is only reproducible on very specific conditions (phone should be in offline mode and wi-fi adapter hardware should be turned on and off several times in a row). But thanks for guidance nonetheless, maybe it will help me in other debugging troubles.
Haspemulator
2010-09-09 03:03:27
A:
I had the same problem which, the OS gives you no help whatsoever.
What I did, which solved my problem and actually helps a lot, it to come up with your own manual stack trace implementation. See parts of my version here (which happens to be the same question you linked to).
My answer has lots of pros and cons.
- Pro - you get a good stack trace that helps a lot in debugging.
- Con - lots of manual work to implement and to maintain.
- Con - may cause performance slow-downs (I set mine up so it only gets compiled for debug builds only).
Shane Powell
2010-09-08 23:19:47
Thanks for answer. I already use this technique (`__PRETTY_FUNCTION__` and stack objects) to trace some parts of my code. But my codebase quite large and it would be a pain to add trace calls into every function (and surely will slow down the execution, which is currently quite low speed already due to large amount of logs).
Haspemulator
2010-09-09 03:10:07
Performance is why I only enable it in debug compiles, not release compiles. And you are right it is a pain, but it was the only way I tracked down some of my kern-exec bugs so I think it's worth it. Once completely in place, it's just a matter of keeping it up.
Shane Powell
2010-09-09 08:53:02
A:
Don't your logs give you a hint? Add more logs around the place it crashes or comment out some blocks to see if the crash happens in them.
Riho
2010-09-09 08:04:19
Unfortunately, no. My program works in asynchronous way, and there are quite many Active Objects running simultaneously. I've tried to log them all, but still with success - error somewhere else. Seems that the only working decision is really to log each and every function entrance and exit...
Haspemulator
2010-09-09 09:49:13