grosgood
commented
4 months ago Hi ThioJoe, First, thanks for the really really detailed bug report. Few appreciate the effort involved in putting together such a report. Tip of the hat to you, sir.
Second, apologies that no one replied really really quickly. We're a small group with daytime jobs.
Third, my suspicions center on the G'MIC shared command. The command allows a component of one image ('donor') to be constituted as a separate image ('share'); from there forward manipulation of 'share', functionally a separate image, impacts 'donor' as well. Perhaps 'donor' shares out one of its channels (say channel 0, representing red data, as in the debug dump). Then the second, shared out, image seems to be only a single channel image, a grayscale — in fact, it is sharing the donor's red channel. Change the gamma of of 'share', and the red channel of 'donor' sees a gamma change as well — because it is shared memory space between two images! There are other ways to do such a thing, but with super-huge images and a constrained memory setting, the shared command is tempting.
Now, there is a protocol in using the shared command: Don't delete the donor while share images are still extant! Do so, and the shares now have pointers into a block of memory that has been reconsigned to the heap — maybe, because it's not quite clear when heap clean up occurs vis-à-vis the running gmic process. But, if the stars aren't aligning, then further operations on the now-dangling-share images will be detected by the OS as an access violation, which leads to an immediate kill of the gmic process — it doesn't even get a chance to wind down; the OS no longer trusts gmic's use of memory. That explains the utter silence of the crash. No exception stack, no die message, nothing. Maybe you get the shell prompt back. Maybe Blue Screen Of Death. It also explains the randomness of the bug's behavior: the gmic process is racing heap clean-up. Sometimes it wins.
I see you've dropped a comment at discuss.pixls.us. Will drop a word there to look here.
In the hunt now. Thanks for the report!
ThioJoe
I've been messing around with the continuous droste effect and have been having repeated issues, both with the GUI for the photoshop plugin and the CLI.
Here is an example of a command I'd run, where the droste component of the command comes from copying directly from the Photoshop plugin GUI after resetting to defaults parameters:
gmic -input 1000.png -souphead_droste10 40,100,1,1,1,0,0,0,0,0,1,10,1,0,90,0,0,0,0,1,0,0,1,0,0,0,0,0,1,0,0 -output output-1000.pngExtremely often, but not quite consistently, it fails like this, for no apparent reason, it just stops:
The verbose output seems to suggest it stops at a particular fill command. I'll paste a debug output at the end:
What's strange is that at one point, using the same command, it started working if the size of the image was smaller enough (roughly 1000x1000 or less), but now it doesn't again. I've also tried this in a virtual machine and it does the same thing. And it also does it with both version 3.3.5 and 3.3.6, and with both update335.gmic and update336.gmic, which I tested by specifying the exact filter file version:
The same thing appears to happen in the photoshop version though, and this one at least gives some kind of error message. In this case, the error occurs immediately when clicking on the Continuous Droste effect, or if the effect was already selected (and therefore it tries to open that immediately), the error occurs immediately after trying to open the plugin:
The error 0xc000008f means "Floating-point inexact result". (Technically it could also mean "The system cannot join or substitute a drive to or for a directory on the same drive" but I think the other meaning is more likely).
The reason I noticed image size might be a contributing factor (but not the only factor) is that for a while it worked in the photoshop GUI when I was trying to do the effect on a very large image (6000x6000) and the effect preview window was able to show the effect being done. But if I tried to hit "apply", it would crash, and if I expanded the GUI preview window too large (as to expand the preview image size) it would also crash. Therefore I tried downsizing the image and then it worked in the CLI where it wouldn't before with the large version. But again, now for some reason it won't even work with those same exact smaller images.
Windows Event Viewer log shows that it is indeed the same crash whether in the GUI or CLI, as you can see the "Exception Code" is the same one that is shown in the window of the GUI when it crashes:
What's more concerning is if I try to run the command via the CLI too many times in succession, it causes a BSOD. And by this I mean, the command fails and gmic.exe exits, and the terminal window shows the C:\whatever> prompt again, and if I do that too many times in a row too quickly, it BSODs. After it happened the first time, I tried the same thing again to see if it was a fluke, but it happened again. See the event viewer log below showing the crashes (these events don't have info about the cause). The actual stop code for both BSODs was
0000007EakaSYSTEM_THREAD_EXCEPTION_NOT_HANDLED.More strange behavior - I just tried to replicate the BSOD issue in a virtual machine, and while it didn't seem to cause it, it demonstrated the weird inconsistency I was talking about. Here you can see the same command ran back-to-back 5 times and failing each time, but randomly working on the 6th time (see that it actually got to the "output image" stage):
Here's a full debug example: