I now have a habit of asking for the Exception Detection and Reporting (ED&R) log as a minimum, and the core file if available, whenever QA observes exceptions during testing. If you are not a VxWorks 6.x user, ED&R log is like a signature of a core dump. It briefly describes the exception by providing the address of the crash, stack backtrace, register values, and even a disassembly of the surrounding code. Core file lets one use Wind River Workbench debugger and other host tools, like the host shell if you like to use command line to dump memory and see tasks at the time of exception. In many cases this all I need to pinpoint the root cause, and fix the defect.
Alternative used to be rather painful, time consuming, and much less deterministic. It preempts what I was doing, so that I can setup my environment to recreate the same crash scenario based on the description of the eye-witness (i.e. the tester). If the bug is obvious enough this method works, of course. But, what if I can't reproduce the crash? Was it a faulty setup in the QA lab or was it some rare race condition that caused the exception? And, if I do reproduce the crash, the first thing I'll probably do is to look at it using a debugger, which is what the core file gives me to start with.
ED&R has been part of VxWorks since version 6.0. Memory based core dump is supported since Wind River Diagnostics 1.0 with VxWorks 6.2 and later.
Both ED&R and core dump support requires a bit of planning ahead of time. It would be too late if the features were not configured in the VxWorks kernel when the exception happened. So, they must be included in the image.
If a Wind River Diagnostics Server is installed it can automatically upload ED&R logs and core files from all the devices in the QA lab. Once the logs are in the server, all a tester would need to do is to reference the device id in the new defect report. Afterward, any developer can connect to the same server and download all the logs from the device using a Web interface or through a Wind River Diagnostics plug-in to Wind River Workbench.
I am again a little bit biased perhaps. Hopefully others are benefiting from these technologies as well.


Bulent Kasman has over 20 years of experience in developing systems and network management software. Currently, he is the architect of the Diagnostics product line at Wind River, where he is designing applications to quickly diagnose and repair errors in device software.



Recent Comments