Corruption from Images
ambassador at fourthworld.com
Mon Aug 2 17:38:21 CDT 2004
> 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. :)
Fourth World Media Corporation
Rev tools and more: http://www.fourthworld.com/rev
More information about the use-livecode