File Corruption

[Richard Gaskin]

Howard Bornstein wrote:

>> But if the problem is related to code in the IDE, it's a bug in the IDE
>> and/or the engine (ideally a 4GL should never have a hard crash), but not
>> necessarily a matter of corrupted data.   "Corruption" refers to bad data
>> structures, not procedural bugs.
> 
> Well look, I don't want to quibble about terminology. Isn't it possible
> for the IDE to corrupt its own internal data structures?

My interest in re-examining the use of "corruption" was less a refection of
my admittedly curmudgeonly nature than a sincere desire to see a proper
diagnosis of the root cause.  If we attach a label to an issue before fully
understanding the cause, we risk overlooking other options that might lead
us to the solution.

I agree that it's too early to determine that corruption of the object
within the file did not occur, but with such a low incidence rate on record
it may not be optimal to focus on that.  We can't rule it out, but we can't
settle on it either.  It seems we need to keep our eyes open to wider
possibilities.

What's most baffling to me is that the cloned object exhibits no erroneous
behavior; I would have expected that if a problem existed in the original
object it would be carried over to the clone.

> My whole point in responding to your original post is that, in my
> experience, Rev has ended up "corrupting" stacks in a way that was
> probably not caused by write operations to the disk. The stacks didn't
> fail because of bad programming. The stacks failed because Rev
> scrambled something in the stacks and then when it went to interpret
> the stack, this scrambling caused Rev to crash.

Corruption can indeed happen prior to a write, in any program.  If it's junk
in memory it'll remain junk when saved, even if the save itself is not the
culprit.

There are too many unknowns to rule nearly any possibility just yet,
including programming: your code may be fine, but Rev's IDE uses complex
libraries which may possibly have an affect on this outcome.
 
I respect your need to move on with your workaround, but curiosity has me
wondering:

- does the crash happen in a standalone?
- does it happen in the MC IDE?
- does it happen on more than one system?

The answer to each of those questions would help successively bisect the
solution space to hone in on the root cause.

Here's an anecdote that may or may not be relevant but will hopefully be
interesting:

A couple years ago I was porting a SuperCard app to MC, and I found I was
getting crashes on a particular card during redraw.  My first thought was
"corruption", and was concerned that I might have to replace the entire card
(the common solution with HC 5454 errors).

Scott Raney had me send him MacsBug dumps and he worked very dilligently in
diagnosing the issue, at last arriving at an understanding:  the line
graphics on that card were the root of the problem, having been created as
two-point polygons with a fill color assigned and the filled property set.
Apparently there is a bug in QuickDraw which crashes when trying to fill a
two-point poly (the error was a "divide by zero" if memory serves, which
would make since as there is no region to fill in a two-point poly).  So
while I had initially panicked at the thought of replacing so many objects,
it turns out all I needed to do was write a loop that turns off the filled
property of the poly graphics.

I guess the moral of the story is that sometimes an issue can look like a
duck, walk like a duck, and even quack like a duck, but turn out to be a
QuickDraw bug.  :)

> Unfortunately, the stack contains proprietary data. If the Rev team wants
> to look at it, I'm happy to make it available.

Hopefully you'll get a reply and they'll see what can be done.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge 2.2: Publish any database on any site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc