ImageFx 4.1 crashes with debug kernel

I'm using ImageFx 4.1 (18.10.1999) with AmigaOS 4.1 (X5000). It is pretty stable, but if I enable debug kernel (kernel.debug on Kicklayout) and try to open ImageFx it crashes immediately, with 'Guru' 8000003. Is there any fix or workaround for this issue?

Here is the debug code:

@Rolar
Quote:No, it's a bug in ImageFX.
The debug kernel sets some data pointers which are documented to be uninitialised to special values, in this case 0xCCCCCCCC, to make it easier find such bugs by intentionally making software crash accessing invalid pointers.
Developers of AmigaOS 4.x software with such bugs in their code can check the stack trace to get the source file name and line number of the broken code.
For using old, broken software using the non-debug kernel instead is the only option, but even if it doesn't crash immediately with the non-debug kernel it may still crash later "randomly".

There is a newer version 4.5 of ImageFX, but I don't know if this bug is fixed in it.

Someone with access to the kernel sources could check in which parts 0xCCCCCCCC is used, other special values used in the debug kernels are for example 0xDEADBEEF, 0xDEADC0DE, 0xABADCAFE, etc., and by checking which special value is used in which parts it may be possible to find out which functions or which data types are used in a wrong way. But that would only help for still developed AmigaOS 4.x software, not for old AmigaOS 3.x/m68k software.

Quote:
I've no access to the sources, but according to the wiki:

Quote:
And:

Quote:

@Rolar

ImageFX has always failed this way on startup with a debug kernel. It just shows what sloppy code we got away with back in those days. In this case, accessing the Prev/Next pointers in a node that has just been removed from a list. Another frequent coding error is to free some memory, then access something within it in the hope that it hasn't yet been destroyed.

The debug kernel shows up these and other glaring errors, at the expense of a slight speed decrease. Any programmer worth their salt will only ever run with the debug kernel, as the "release" version is likely to crash the whole system in the same circumstances.

Fortunately, the Grim reaper allows the user to "Ignore DSI Errors" and continue from a crash. ImageFX runs OK after that.

@tonywQuote:

Actually it is not necessarily a bug/coding error. Docs do not say that accessing Prev/Next after removing from list is forbidden (for example on a private list, not some shared msgport list like window userport) and furthermore the internal implementation of list functions is exposed in assembly header "exec/lists.i".

@Georg

OK, it was not forbidden by law or documentation in those days, but it is dangerous and certain to cause a crash some time.

The only safe way to get the Next node AND remove the old one from the list is to:
(1) Get the next node first;
(2) Remove the old node.

Of course, you should have unique ownership of the list when you do that, to prevent other tasks interrupting and changing the list while you are trying to do the same.

We are trying to reduce the amount of internal structure that is exposed to the user. What was tolerated in the days of 68k assembler is often deprecated now.

@Georg
Quote:They do:

@joerg

Well, but then basically you break backwards compatibility with older code which may rely on the fact that previously Remove was known and sort of documented not to modify ln_Succ/ln_Pred. Accessing ln_Succ/ln_Pred is/was not automatically a bug. It could still be correct/non-broken/non-crashing code, maybe something like this (of course not doing it like this is always better).



So there will be code out there in the wild accessing ln_Succ/ln_Pred which is really buggy, but also code out there in the wild accessing ln_Succ/ln_Pred which is not buggy at all. I don't know the ratio. But you now will get this crash/DSI thing, which sometime may "prevent disaster" and sometime just be a false alarm or maybe even "create disaster" as the formerly safe code no longer can traverse through the whole list as ln_Succ/ln_Pred after Remove() no longer points to the (former) next/previous node.

Quote:

Okay, if it is a real bug of accessing ln_Succ after Remove(). But if it isn't (the user doesn't know) then some code supposed to be executed on maybe all list's node isn't being done as the ln_Succ Poking by Remove() prevents that.

@Georg
Using such broken code might have been an excuse for ImageFX version 4.1 (from 1999), but not for the current version 4.5 which was released in 2020.

The AmigaOS 4.x exec isn't based on any of the AmigaOS 0.9-3.x exec sources (at least 95% of it was useless m68k assembler code anyway) and for most parts there was no reason to duplicate bugs in the old implementations.

Backward compatibility to broken AmigaOS 3.x software was always a low priority in AmigaOS 4.x development, and for some important software there is, or was, a config file to add workarounds.

Making broken software crash isn't even something new in AmigaOS 4.x, AmigaOS 1.x-3.x debugging tools like Enforcer, Wipeout, MemGuard, GuardianAngel, etc., did something similar 20-25 years ago already.

@Georg
Quote:The exec AutoDoc includes a working example code for it:

I have to agree with Joerg and Tony here, attempting to traverse a list whilst modifying it has always been a bad coding behaviour, and the fact you could get away withit was just "luck". Try it with a C++ list where the equivalent node structiue is fully encapsulated and bad stuff will happen if you don't do it the right way.

But as regards to backward compatabilty, the crash is only enforced with the debug kernal, which is for developers and debugging and should not generally be used by end users.

Even in Java..