Corruption from Images

[Richard Gaskin]

pkc wrote:

> Hi Richard, thanks for that terrific essay. In principle I understand 
> what you mean. How can a person tell if an "image object" is actually 
> corrupting the stack?  I never got any corruption messages from 
> Revolution, and never even thought of corruption until Ken found it. 
> Revolution happily ran the stack in the IDE, built both the OS X and 
> Windows apps without comment, and the OS X application runs fine. The 
> only hint of trouble came when the Windows app had reached it 
> destination and couldn't be opened. I wonder if there is any way to get 
> a hint of impending trouble during the compilation or during the build?

Did you run the stackfile in the Win IDE?  When a standalone exhibits 
problems not evident in the Mac IDE, that's sometimes useful.

As for honing in on a corrupted object, first thing is to forget about 
corruption until the engine tells you a stack is corrupted.  ;)  Only 
after you run it in the IDE and it reports that it's corrupted is it 
worth going down that tedious road; in most other cases it's just a red 
herring that'll eat your time but not help you identify the actual cause 
of an issue.

But if the engine says a stack is corrupted, first check in the 
directory where the stack is located for a "`" copy (i.e., if your stack 
file is named "MyStack.rev" you'll likely see a stack named 
"~MyStack.rev").  This is a backup, which the engine makes automatically 
when you execute a save command. In 99% of cases where a stack is opened 
and the IDE reports that it's corrupted you'll find the automatic backup 
waiting for you, so you just toss the bad copy, remove the "~", and 
you're back in business with everything up to your last successful save.

In the very rare case where the engine will report that a file is 
corrupted and no "~" backup is available, the trick to finding the 
object giving you the trouble is like any other good problem solving: 
bisect the range of possibilities until you find it.

This assumes, of course, that you're able to open the file on at least 
one system. But if you can I would do this:

- Make a copy of the file.
- Delete half of the substacks.
- Try to open the file on the platform where the trouble
   was last reported.

If no error is reported then you know the offending object was in one of 
the deleted substacks.  If an error is reported then you know it's in 
one of the remaining substacks.

So then make another copy of the original file and try it again:  delete 
half of the suspect substacks.  Repeat this until you get down to the 
one containing the object which is causing the error.

Once you find the troublesome stack, the first thing I do is try 
deleting all of the image objects there.  If there is no problem then I 
can rule out image objects and focus on others.  If the problem goes 
away without the image objects then I've verified my hunch, and can go 
back to a fresh copy and delete just half of the image objects, and so 
on, until I get the one causing the issue.

Once the offending object is found -- and this is the most important 
step -- send the stack file to support at runrev.com with a report letting 
them know what you've found and what they'll need to do to see the 
error.  If you have the original image file that can also be very 
helpful, as the problem may be with something related to importing it or 
something in the image data itself, and having the original source image 
file will help them make that determination.

Fortunately this sort of thing is very, very rare.  If your experience 
is like mine you'll go another seven years without ever seeing another 
corrupted object. :)

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________
  Rev tools and more:  http://www.fourthworld.com/rev