I had my suspicions but now I confirmed it:
The Grim Reaper in OS4.1 update 2 is broken and cannot kill any programs without creating an endless recoverable 0100000F error needing a hard reset.

I had this issue with SabreMSN when it occasionally crashed. Now Timberwolf crash and I tried to kill it and got the same thing. And now last time with a freshly booted system I tried the following:

Created this extremely simply program:

main() {
int *x=0, y;
y=x[0];
}

Compiled and executed it and got the Reaper as expected.
Clicked Kill and got endless recoverable 0100000F alerts.

Conclusion: The Grim Reaper is broken!

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

Also after it is activated, reset by keyboard becomes impossible. This is inferior to at least OS 4.0 Final (Grim Reaper 53.2 if I'm not mistaken). The system will just freeze, so I then reboot from GR or shell.

_________________
: AmigaOneXE (unmod.) 750FX/512 MB +stuff & AmigaOS 4.(0|1)
: A1200/68060&96MB/SCSI/EM1200-Voodoo3 & OS 3.5
: A500/1MB
: Pegasos (ff) 512 MB & MorphOS
Praise seitan.

Could this be confirmed or rejected by some beta tester or else involved person?

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

I have write about it on amigans.net in os4-bugs thread, which one of developes (Rigo) are reading. So after a while i think he can answer about.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@Deniil715

I'm sure I tried to kill somethings recently and they just crashed futher which didn't make sense. Usually a Kill is a safe operation!

I wonder, if it ain't broke why fix it so it is broke? A1 serial. USB printer. The list goes on. We could add more.

@Hypex

I think they wanted to add some much wanted features to the Grim Reaper, such as memory cleanup or perhaps other garbage collecting features, but something seems to have gone wrong.

I would love the Reaper to for example close the window of an app because and orphaned window makes the system extremely instable - click on it and it locks up. Most probably reason: The title string has been deallocated but the window (i.e. intuition) still tries to use it and crashes.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

I had to kill AWeb last night, and it behaved as expected.

However, when I killed xvic.exe from VICE the other night, my Sam crashed, as mentioned in this thread:
VICE 2.2 xvic.exe and xpet.exe working?

Maybe xvic.exe stomped all over other programs that were running, though. It may noy have been GR's fault.

@Deniil715

There is answer from Rigo for you

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@Deniil715

I've seen the same behaviour replicated, so yes it seems it is broken.

@danwood
Read Rigos answer too.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Quote:

There is answer from Rigo for you

That answer is just silly. How is that test program supposed to have corrupted the memory list? It does nothing but a *read* from address *zero*....

@umisef
I repost your message on amigans, but better if anyone in interest can post it himself later :)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@Deniil715
Quote:

Conclusion: The Grim Reaper is broken!

That may not be a completely accurate conclusion. I compiled your test program and ran it several times from a KingCon shell and an Amiga shell. In both cases I could not confirm the behavior you describe. I'm using a SAM Flex and compiled the test program with the latest SDK.

Is anyone else who confirmed the Grim Reaper problem using a SAM or SAM Flex? If it's only occurring on an A1, that might be crucial information for tracking down the problem. If SAM users can reproduce the problem, then there must be something different about my system (Settings, SDK used for compile, other Apps running etc.)

_________________
X1000 with 2GB memory & OS4.1FE

@Xenic
I compiled & tested the program, and it was fine on my Sam440 running OS4.1.2 .

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@Deniil715
I know at least kill has never ever worked on my system at least.

@umisef

Will do last re-poster job about that subject from Rigo on your message:

"Correct me if I'm wrong, but I didn't say that the test program actually had corrupted any memory list, but that the reccuring DSI's are "insanity" errors caused by a corrupted memory list.

Perhaps your "other user" should read what is written before sharing their knowledge and wisdom.

EDIT: Out of curiosity, I tried the test on my Sam running the public Update 2 installation, and I cannot reproduce the described behaviour there either. I can only conclude that the author has some program or patch running that is causing the problem somehow. I get the GrimReaper appear, and both "Continue" and "Kill" work exactly as expected. So no, there is no problem, here at least."

But looks like futher discuss about subject will make no sense, so, i am off here

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

(@rigo@amigans)
Quote:

Correct me if I'm wrong, but I didn't say that the test program actually had corrupted any memory list, but that the reccuring DSI's are "insanity" errors caused by a corrupted memory list.

No, rigo just wrote 'The endless stream of "insanity" errors in his test case is the cause of a corrupted memory list, not GrimReaper.' and 'The state of the system after any crash is not guaranteed' (emphasis added).

Now, if his intent was to communicate "It appears as if the memory list on his system was silently corrupted prior to running the test program which causes the crash, and the GR's recurring failures, caused by this pre-existing corrupted system state, would occur regardless and independent of what caused the GR to be invoked", then he did a pretty lousy job.

Quote:

I can only conclude that the author has some program or patch running that is causing the problem somehow.

Except you have MichaelMerkel post "on my normal system, bootet with no-startup, loadwb "manually xeceuted" and no wbstartup at all, grim reaper also crashes!"

Was the cause for the display-corruption-when-not-using-debug-kernel-on-SAM ever identified and fixed? Or did that just happen to go away when some module sizes changed? Because it sure sounds like something deep in the heart of OS4's startup is corrupting memory somewhere...

Anyway, this should really be seen as an opportunity. There is a reproducible and detectable corruption of system state on some systems. Something reproducible and detectable can be debugged. So why not create a small program (and/or possibly a kickstart module) which checks the memory lists for integrity. Stick it into various places during bootup, and narrow down at exactly what point the memory list gets corrupted, and what address exactly gets corrupted.

(From then on, things are a lot easier when running under emulation --- there you simply instrument the emulator to log every write to that particular address, then work out which one of those is the naughty one, then instrument the emulator to drop out of emulation and into system inspection mode on that particular write, look at the code that caused it, probably find that it itself got wrong data from somewhere else, and repeat the cycle until you find the root cause of the problem.
Without such ability to supervise execution, life gets more difficult --- you then have to instrument the actual code at fault to log its writes somehow, and hope that such code modification does not change behaviour enough to make the problem disappear [and come up with less disruptive logging methods if it does].)

@umisef

The way I'm reading the test program, it puts a zero in memory location x without defining it first. So it puts zero in an unknown location, then tries to read it. That might not always cause an error. It depends on where x is.

_________________
X5000 / microA1(OS4.1 FE U2) / CodeBench / Imagine / Blender
Lightwave 2019 / Microsoft Visual C++

@thinkchip

Quote:

The way I'm reading the test program, it puts a zero in memory location x without defining it first.

You are reading it wrong, then :)

"int *x=0;" is equivalent (to the level of detail relevant to this point) to "int *x; x=0;", not to "int *x; *x=0;".

In other words, it declares a pointer and sets it to 0, rather than declares a pointer and writes 0 to whatever that unitialised pointer points to.

(And yes, I personally would write that as "int* x=0" for that very reason --- the type of x is int*, and thus assigning 0 to x means assigning NULL to a pointer; However, the preferred way of writing it in C is "int *x=0", i.e. saying "*x is of type int" and then breaking the connection between the '*' and 'x' when it comes to the assignment. This convention is further supported by the rules for interpreting "int *x,y" --- "*x is an int, as is y", and the confusion one can create by writing "int* x,y", which would suggest that x and y are of the same type, namely "int*" --- in C, however, they are not. Similar fun can be had with the binding of constness, volatility or other attributes.
Based on all this unfortunate historical baggage, the recommendation given in C programming courses these days is "One variable per declaration!". Real world usage may add a "except where the declaration is for unmodified, non-pointer data types without declaration-time initialisation". And with C++/C99's more relaxed rules about declaration placement [particularly for loop counters], even that exception gets little use in modern code)

Last edited by umisef on 13-Jul-2010 at 04:36 AM.

@umisef
We were told the Sam non-debug-kernel corruption bug had been identified & fixed, although I can't say how accurate that was. At least I don't get that problem any more.

P.S. I honestly mean it when I say: Nice to see a constructive (and non-bitter) post, as I thought you'd forgotten how to do those. Hope you keep it up.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...