Continuous Droste Floating Point Exception (Bug?)

Software G'MIC
,
11

Nothing so gauche as the donor image of a share being removed whilst child images are still extant, but a design based on shared still…

As observed, a fill command pel processor implements the whole of the droste algorithm (thanks be to Jos Leys for furnishing really nice documentation). Authored by Martin Souphead, Continuous Droste has been around since 1.6.9.

Martin’s game is to:

  1. Load an image ([0]) This is the provided reference image.
  2. Use to_a to endow the reference image with an alpha channel, in case it does not have one.
  3. Create a new image ([1]) with the image geometry of the reference image (with alpha channel, so each pixel of the reference and and new image is a vector4. The new image starts life with all pixels [0,0,0,0]).
  4. Share out channel 0 (red) of the new image to make the third image in the stack ([2]). This third image has the structural appearance of a single channel grayscale, but that channel is shared with its predecessor’s ([1]) channel 0.
  5. Harness fill to house a mathematical expression that nominally iterates over the pels of the share ([2]), but, in practice, also writes to the G, B and A channels of the donor image [1]. So, in effect, Martin is processing [RGBA] vector4’s in image [1], while iterating over the shared-out R channel constituting image [2].
  6. When the fill iterator finishes, the algorithm has fully executed. Martin keeps [1] implicitly deleting [0,2].

Since he is keeping the donor, and deleting the share and reference, there is no obvious share violation. I find the filter’s design ingenious but — in this day and age, the share operator is unnecessary. in the world of modern G’MIC (3.x) we can iterate over images a vector at a time.

It seems to me, in fact, that the fastest way to fix the bug is to get share out of the design; iterate over image [1] with a full pixel processor. Won’t take much re-writing at all. I think if Martin would stop by now, eight years after his original design, he would do that as well. He certainly exhibited sufficient cleverness back in the day, and with the expanded iteration capabilities of G’MIC 3.x, he would opt for the cleaner design.

This puts to one side the still-undiagnosed issue with share. I really do think it is an issue with share — specifically, G’MIC is earning itself a kill signal on @ThioJoe 's Windows platform. The abrupt way of G’MIC’s departure is a hallmark of kills arising from access violations, and, by its nature, share is well-suited to set up such calamities. Certainly, not by design, but by some as-yet unnoticed share bug with an esoteric trip-wire. In this particular instance, what’s the wire? I dunno, but I mistrust share. It is a tricky command. I’ll bet my pocket change that if it was written out of the filter, the bug would go away. @David_Tschumperle may react with dismay at that — there is something lurking in share still, making G’MIC less solid than it could be. My scheme walks around the issue instead of addressing it head on, but it seems the expedient approach for a near-term release. The root of the issue, given the infrequency of its occurrence (few people seem to experience it) suggests that it will be hard to find. Feels to me like gdb sessions on the C\C++ side of the fence.

Well — I could use some practice in that, I suppose…

EDIT:

That’s also interesting. As noted, the algorithm is almost entirely implemented in a math expression. Possibly not share at all, but a math expression parser oopsie…