Chris McKillop wrote:
Igor Levko <firstname.lastname@example.org
Let's get back to the source. Igor's original statement was
"That manifests itself as system not doing anything except for spitting 'Out
of interrupt events' on the
screen continuously. The end result is, you have to reset it. It is as good
as a crash."
As far as I can tell, this is only going to happen when you use
InterruptAttach() and your ISR does not call InterruptMask() before returning
the the event to the thread. In this case the ISR will continue to fire,
and depending on timings, the handling thread may never get to run. This is
a bug in the driver. And just shows that igor's original statement, that when
you touch hardware there is no "crash proof", to be true. Just happens that
QNX is 10x better at managing the cases where the hardware isn't screwed up
(null pointer reference).
QNX (at least QNX4) seems to just be better at protection, even when
comparing process to process (i.e. not even considering the in-kernel
driver case). At the last company I worked at, a developer wrote and
"debugged" a program on his NT workstation, that I was to incorporate
into a controller with no MMU. His code had a test scaffold built-in,
and, as per our SOP, I compiled and ran it on QNX4, just before
incorporating it into the controller (for FDA doc purposes). It
SIGSEGV'd immediately. The same code executed without error on NT.
I quickly re-ran it inside the debugger, and sure enough there an
invalid (not null) pointer de-reference (which, incidentally, was in the
test scaffold and not any of the code to be incorporated into the
There are probably many reasons that NT didn't catch it (some of which
could be simple luck-of-the-draw - i.e. the value of the invalid
reference), but I have never had the opposite situation occur (i.e. NT
catch a bug in QNX code, that wasn't caught by QNX). I suspect that NT
provides a lot more "slack" backed VM to a process than QNX does.