It is frequently not too hard to track down the cause of RB
assertion failure; I've nailed more than one. As I recall, many of
them were due to RS' failure to anticipate some utter stupidity on
my part.
lol, well I dont know about easy;) I have never hit an assertion
failure that was 100% repeatable. I've hit a fair number that were
VERY complicated to reproduce. For example I'm currently working on
one that bombs in Objects.cpp:401 but only after the program has run
the offending code a few hundred times, and only if a dozen other
things have happened within a certain amount of time. My hopes for
nailing it down to something I can bug report are almost nil. It
cannot be made into a simpler project.
But while wasting a lot of time messing with it I've learned enough
that I think I can work things out to happen less, but I dont know
yet it's very difficult to test as you can imagine. There are no
measurable memory or object leaks or anything else obvious going on
and the code works every other time it runs just fine. It's one of
the dreaded timing issues.
I wish there was a way to not display those dialogs in shipping apps.
If an app crashes I need to to just crash, I do not need it to hang
with an assertion failure dialog with OK as the default value. almost
invariably when a user sees one of these things they click OK, which
on OS9 often leads to the machine crashing instead of just quitting
the app which would have left the machine running OK. Or they click
OK and the program continues to run, at least for a while, with other
strange results happening later on. This dialog needs to have QUIT be
the default option.
-James
--
_____________________________________________________________________________
James Sentman <james at sentman dot com>
http://www.sentman.com
Enterprise server monitoring for Mac OS X: http://whistleblower.sentman.com
|