Reporting Exceptions in QA

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.

Continue Reading ››