ITDS = It's The Driver Stupid!

8 views

Skip to first unread message

BruteForce

unread,

Nov 22, 2006, 7:33:49 AM11/22/06

to FireAPI

You have probably heard the now famous "It's the economy stupid!" or
the also famous to some KISS (Keep It Simple Stupid). Now it's time for
"It's The Driver Stupid".

Let me tell you one principle by which we at Unibrain abide:
No user of FireAPI or FireiAPI should be able to crash the system.

To put it another way, no matter what you do in your code if you
somehow get the drivers to crash the operating system then the Unibrain
drivers are to blame. Microsoft is not to blame, Murphy's law is not to
blame, your potentially incorrect code is not to blame.
Yes, even if your code is incorrect it should ONLY fail, NOT crash the
operating system.

The trigger for this post was a truly interesting support case. The
code was doing its isochronous receive by copy-paste programming from
the isochronous samples. However there were some subtle but very
crucial changes.

When you call C1394IsochQueue you pass an array of
FIREAPI_ISOCH_REQUEST pointers. The function documentation clearly
states that the array of pointers can reside on local (stack) storage,
because the function internally copies this array so it is safe to
delete it as soon as C1394IsochQueue returns. However what the
documentation only implies is that the FIREAPI_ISOCH_REQUEST structures
should stay alive for the duration of the isochronous operations.
This, in most cases means "Do Not Allocate on the Stack". It also means
"If you allocate on the stack make sure that the stack position is
valid throughout the isochronous operations".

The isochronous samples declare the FIREAPI_ISOCH_REQUEST structures on
the stack, but then the stack is main's stack, which means the
structures are alive throughout the isochronous operations. However the
offending code we met, copy-pasted main's logic into another function,
that did a couple of things and then returned. This left the drivers
with some invalid user mode pointers.
What happened next is of interest only to kernel-psychos, but the
symptoms were that the second time you exited the application, there
was a blue screen or instant reboot without a blue screen and no kernel
memory dump. Now that's what I fancy about it. Not the first time, but
the second time you exited the application.

So if you ever crash the ubCore drivers and the crash goes away after
fixing your code, please please please let us know how you managed to
crash the drivers so that we can fix the bug, even if it is a
borderline case.