VxWorks exception handling and division by zero

I’ve been wondering how VxWorks on the cRIO reacts to uncaught exceptions in the user program. As I understand it, the user program is loaded as a kernel module, so it seems like an uncaught exception should result in a kernel panic. I wanted to test this out, so I wrote code that I expected to throw a runtime error on a button press. I tried a piece of code that would simply output the result of “1/0” to stderr. The result, however, was that “0” was printed to stderr, and no error or unexpected behavior occurred. The same code snippet,

std::cerr << 1/0 << std::endl;

in a native program caused a crash. So now I am left with two questions:

How does VxWorks respond to an uncaught exception in a kernel module?

Why is the result of “1/0” “0” in WindRiver C++?

The reaction to an internal exception in VxWorks is customizable (so NI might have changed it). One can register signal handlers to trap exceptions and implement behaviours other than the default.

Even though the NI tasks and our robot application code are running in kernel space or context, the kernel context supports multiple tasks. The default reaction to an internal exception is to suspend the offending task, store some data in a special area of memory (so it can be examined after a warm reboot) and log a message. It is the exception handler task that implements this behaviour and the log message task that prints the message.

I am not sure about the 1/0 statement. My first guess is that would create an exception. Perhaps C++ traps that somehow or perhaps NI is trapping it somehow. Maybe the C pre-processor resolves 1/0 as a constant and the PowerPC never sees the statement. Try using 1.0/0.0 or using a variable (set to zero) in the denominator - that will probably create the exception more reliably.


You can also experiment with dereferencing a bad address, double freeing an allocation, etc. It feels odd to write programs that you know will crash, but learning how they present their crash is very helpful later when it is not you, or it is an accident.

Greg McKaskle

Sorry for not replying for a while, it’s been very hectic. 1/0 and 1/any variable set to 0 will both produce the same output. 1.0/0.0 will produce inf. I also tried dereferencing a null pointer, and it had much the same effect (that is, none). I’ll try to test raising other exceptions when I get the chance.