Guru vs. Grim Reaper

I know that I should not do that...

Try to start GrimReaper with any argument. It crashes badly.



Lazi

@lazi

Quote:Not for normal crashes, even the inital requester is in GrimReaper, only for ramlib crashes there is a requester in reaper.

Quote:C:Reboot doesn't work with the arguments passed to GrimReaper, try a script with something like
Reboot FAST
as SYS:System/GrimReaper. Don't forget to set the 'S' protection bit when using a script.

Quote:Rename GrimReaper, for example to RealGrimReaper, and use a script as SYS:System/GrimReaper:
.key ARGS/F
.bra {
.ket }
soundplayer path:to/crashsound
RealGrimReaper {ARGS}

@joerg

Thanks a lot, it helps!

@COBRA

What we really need to get rid off is Alerts in general. They have their usefulness in some exceptional situations, but should really be a lot more multitasking-friendly. As it is now, they completely block anything. I guess we should discuss this on the developer mailing list

@lazi

I just re-checked, and I was mistaken about the initial requester. This only comes up if the crashed task is a RAMLIB init task.

One common problem under OS 3.x was that the RAMLIB task ran out of stack, especially with things like MCP. Furthermore, any library crashing in their init code could bring down the entire system because it crashed the ramlib process, making it impossible to open a disk-library afterwards.

We changed that so that ramlib now spawns a subprocess that does the actual opening, and if the opening fails, they also end up in the kernel Reaper, but are handled slightly differently (ramlib will be signaled that a child task has crashed, usually resulting in it returning a failure to the program that opened the library). This signaling is not done for "normal" tasks.

In case of a "normal" (non-ramlib) crash, the kernel reaper tries to launch SYS:System/GrimReaper with a command line argument pointing at the crashed task's struct Task. I suppose in your case, reboot will simply complain about invalid number of arguments, but since the process is started with NIL: and the input and output stream, you don't see that.

Easiest way would be to write a small program that just calls "ColdReboot" on IExec, something like



would do the trick.

@joerg

Quote:

Yep, just found out... The code was written 2003, so I'm a bit out of the loop with it

@lazi

Like I wrote in that other topic, the command line argument to GrimReaper is the adddress of the crashed process, so passing it an 'A' will crash. We could add some magic word to it, but as soon as you knew that, you could crash it just as easily