How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines

[Wilhelm Sanke]

Actually you can choose between two four-liners, depending on the 
specific conditions.

First, a few remarks about the context and the circumstances in which 
such crashes occur:

Starting in March this year, I have sent posts to this list about 
crashes while using image processing tools or scripts, about 6 times 
until now.
In most cases the crashes were of that type where stack and IDE suddenly 
disappear from the screen without a prior error message or error 
announcement from inside Revolution, sometimes the crashes were 
accompanied - on Windows XP - with a Windows system error message indicating

"Revolution Engine for Win 32"

When I hit button "debug" in this Windows dialog, the dissassembler of 
Visual C comes up - first with another dialog showing

"Revolution.exe:  0x0000005 Access Violation"

Then the disassembler of Visual C points to

7C91120E int 3  or 7C91120F int 3

and after releasing the access violation dialog to

00543D45 mov         cl. byte ptr [ebx + edx]"

There is a more detailed report available which is intended to be sent 
to Microsoft Corporation.

Apart from these sudden crashes, where Rev simply vanishes from the 
screen, I got four "corrupted" stacks - stacks that cannot be opened 
anymore - and several times I experienced a certain "damage" in stacks: 
Buttons - and at one time an image - disappearing from an otherwise 
functional stack. In a related case I suddenly happened to get groups 
nested 9 levels deep, although in the script that seemed to have 
produced these nested groups, groups were built and properly ungrouped 
only at two places in the script. The same script - without a change - 
never before and also never after this incident produced such nested groups.

The problem I had with these difficulties and crashes was that I could 
not find out where in the script and how these were caused. The very 
same script could run 30 times as it should and then suddenly produce a 
crash during run time 31.

I had listed some "peculiarities" concerning image and graphics 
processing in Rev in my earlier posts, which might be connected with 
these crashes and irregularities. See an updated list of such 
peculiarities at the end of this post under "P.S."

In nearly all of my image-processing stacks - meaning with the exception 
of one - I never or rarely experienced engine crashes (such as 
"Imagedata Toolkit 
<http://www.sanke.org/Software/ImagedataToolkitPreview3.zip>", "Seamless 
Tiles <http://www.sanke.org/Software/SeamlessTiles2.zip>", "Thumbs and 
Slides <http://www.sanke.org/Software/ThumbsAndSlides09.zip>", "Snapshot 
Teststack <http://www.sanke.org/Software/SnapshotTestStack.zip>", "More 
about Masks <http://www.sanke.org/Software/MoreAboutMasksRev3.zip>", 
"Photo Patchworks",
"Join Overlapping Images 
<http://www.sanke.org/Software/JoinOverlappingImages.tip>", "Dynamic 
Image Buttons <http://www.sanke.org/Software/DynamicImageButtons.zip>"), 
but I got an increased number of crashes and weird behaviors when I 
started working on my "Gradient Kaleidoscope" tool.
For positive results - when the stack was working - see 
<http://www.sanke.org/MetaMedia/GradientKaleidoscopeGallery1.htm> along 
with galleries 2 to 4 accessible from there.
Especially with a new component of the "Gradient Kaleidoscope" tool, a 
script taking hexagonal snapshots from an image and then arranging 6 of 
these snapshots (which could then be modified in various ways) around a 
seventh hexagon to form a new image and shape, I ran into a lot of 
troubles, and then I gradually was able to weed out some of the 
problems. Again, "positive" results of this special component can be 
inspected here:

<http://www.sanke.org/MetaMedia/SevenHexagons.htm>

Characteristic of the Gradient Kaleidoscope stack is the high density 
and interelatedness of snapshot-taking, masking, setting angles of 
images, grouping, ungrouping, re-setting of angles to 0, and the use of 
up to 8 hidden placeholder images that are arranged and re-arranged to 
form the new images and different shapes.

In one of the scripts creating seven-hexagon images I eventually 
happened to notice a constellation, in which I could consistently 
reproduce crashes of the Rev engine. I had ungrouped two angled hexagon 
snapshots to set their angles to 0 and then use the two images again in 
another grouped arrangement. The two scriptlines of the kind "set the 
angle of img "placeholder" to 0" immediately crashed stack and IDE - 
commenting out the two lines prevented a crash.
The entire script contained about 120 lines, so I tried to find the 
relevant elements for the crash and finally ended up with two sets of 
four-liners that are of course connected to certain preconditions. I 
produced a test stack "Crash Recipe" which contains and isolated the 
elements necessary for a crash, and I also added a workaround.that 
avoided a crash to that stack.

First of all, the one image used in the test stack needs to be of the 
"Pre-PNG" type, an image type I have named as such and described in 
detail in my stack "More about Masks"

<http://www.sanke.org/Software/MoreAboutMasksRev3.zip> in the text 
brought up on the menu card from the topright introduction button.

"Pre-PNG" images are basically those that are created or modified (as to 
their imagedata) in Revolution and have not yet been saved as external 
files and then been re-imported. Even if you export a snapshot using "to 
image x as PNG" (image x being an image already existing on the card), 
the resulting image will remain a Pre-PNG, also copying and pasting the 
Pre-PNG to another card or stack preserves the quality of the Pre-PNGs 
which behave differently in some respects. For details see my comments 
in "More about Masks".

For the test stack I created a basic gradient image with the "Gradient 
Kaleidoscope" tool and copied it to the teststack. If you want to work 
with a test stack of your own, you could create an image in my 
"Imagedata Toolkit 
<http://www.sanke.org/Software/ImagedataToolkitPreview3.zip>" 
(preferably a gradient image) and then copy it into your stack along 
with the scripts below.

The second precondition is that "lock screen" is used as the first line 
in the four-liner, without "lock screen" no crashes occur.

Script 1 assumes that you have set the angle of img "test" to an angle 
other than 0 and that img "test" is ungrouped.

  "lock screen
  select img "Test"
  group
  set the angle of img "Test" to 0"

Script 2 assumes that you have set the angle of img "test" to an angle 
other than 0 and that img "test" has been grouped immediately before 
running the script

  "lock screen
  select last group
  ungroup
  set the angle of img "Test" to 0"

Happy crashes now! Happily with these reduced scripts you will not 
produce corrupted stacks.

One workaround to avoid the crash is to take line "set the angle of img 
"Test" to 0" out of the script and put it into a separate button 
script., let us name the button "ZeroAngle".

In Script 1 and 2 then you need to replace the last line by

"send "mouseup" to btn "ZeroAngle" in 0 milliseconds"

The most important part of the above line is "in 0 milliseconds".

I have come across such "out-sourcing" needs several times in 
image-processing scripts, also such where you need not add "in x  
milliseconds".--

I will spend an very extended weekend in "Heidelberg" on urgent business 
and also some diversions (among them anniverseries) planned long ahead, 
unfortunately preventing that I might even listen in to the Rev 
Edinburgh conference. But I wish all participants new insights and 
experiences.

Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

===================================================================

P.S.: Some examples of peculiarities in image and graphics processing or 
related to it:

1. Sometimes using "flip horizontal" 1/3 of a partly transparent image 
is suddenly additionally transparent.

2. Turning the mid-square of an rectangular image (width > height) by 90 
degrees (shifting the pixels by script) results in a semi-transparent 
overlay when the width of the image is odd

3. Some operations cannot be performed on an image when the ink is set 
to "notSrcCopy", e.g. replacing a color or color range by a specific 
other color

4. Exporting a snapshot to an image with a blendlevel (e.g. set to 50) 
leaves part of the former contents of the image intact.

5. With one script I suddenly happened to get groups nested 9 levels 
deep, although in the script that seemed to have produced these nested 
groups, groups were built and properly ungrouped only at two places in 
the script. The same script - without a change - never before and also 
never after this incident produced such nested groups.
The creation of these 9 nested groups was accompanied by a crash, 
question is: Did the nested groups cause the crash or did the crash 
produce the nested groups?

6. "lock screen" is sometimes disregarded (first noticed with version 
4.0-dp1, later also with 3.5) by the engine in scripts of the 
Kaleidoscope stack

7. "Pre-PNG" images are basically such that are created or modified (as 
to their imagedata) in Revolution and have not yet been saved as 
external files and then been re-imported.
 >From the introductory text of stack "More about Masks 
<http://www.sanke.org/Software/MoreAboutMasksRev3.zip>":

"A final observation concerning the creation of masks inside Revolution 
and using the "import snapshot" format:

If the resulting mask image is not first saved as an external file and 
then imported again, meaning if it remains as freshly created inside a 
stack or was just copied from another mask-producing stack, then this 
mask image will have a different quality, which we might call a "pre-PNG".

Pre-PNGs behave somewhat differently than normal PNGs: You cannot 
transfer its alphamask to the image-to-be-masked when the pre-PNG is 
hidden, at least not several times with resizing. After you have resized 
a pre-PNG during the masking process, you might find that it is suddenly 
"empty", but it can be restored when you copy and paste it (it then 
appears in its original size and shape).
A workaround to overcome this problem is to store the mask in a custom 
property of its own and then to "initialize" the mask each time before 
it is used in the calling script:
"put the CPimg of img "transition" into img "transition""

But of course you can easily convert a pre-PNG to a full PNG by saving 
the image as an external file."

8. Again "transparency": Sometimes you need to take a snapshot of 
grouped and partly transparent images twice to get the correct connected 
transparency. I have got a script where is necessary - I do not yet know 
why.

9. Another example of "weirdness": Group names can happen to be 
transferred from one stack to another without having been transferred 
manually or in a script. The following happened:
Two stacks are open. A group is used in stack A as a selection graphic 
and then hidden. An ungrouped image is copied (manually) from stack A to 
stack B. When the image pasted into stack B is grouped now, the group 
(which is not given a name at this point) assumes the name of the group 
last used in stack A, and also the newly grouped image is hidden in 
stack B (as the the group with the same name was hidden in stack A).
When I close stack A, nevertheless grouping the image in stack B 
produces the same results. Only after both stacks are closed, Revolution 
is quitted and then restarted, then grouping the image in stack B will 
work without transferring the group name from stack A.

10. You cannot paint on a grouped image or perform scripted paint 
operations on it. To do so you need to get the image out of the group first.