Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
I did just check ENVARC:ringhio.appsprefs.xml and it's big (~4MB). I opened it with MEmacs and one entry has a lot of garbage in it. I have to delete/rename it and check if everything works better. Maybe there was a system crash during file operation corrupting that file or something. Email sent.
Btw: Why is Ringhio prefs files not in sys dir like other system prefs files ?
(@thread PS. I've been busy and tired lately to remember/realize to check everything myself. And we have heat wave where I live currently. It's too hot indoors to spend any time for computing. Unfortunately there's no Amiga laptop. I have to check and re-check all mentioned problems when this heat wave is over/next autumn.)
Edit: SOLVED !
Edited by TSK on 2010/7/11 22:55:17
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
I'm sure that one has already been filed, I'll check.
I get the same problem here too.
Simon
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
1) When a mutli-assign is made during startup (for instance by MUI in the user-startup), and if there are files with the same filename in both directories, then boot will hang on the splash screen. I've had this happen multiple times, and I've had to remove the MUI assigns from user-startup alltogether. This is NOT very userfriendly at all.
2) The discdoctor (or whatever it is called nowadays)! When a program (for instance Quake 3) crashes in the middle of something with files open, then the disc will be unvalidated at reboot and the discdoctor will initiate at boot time. This might _also_ hang up the machine at the splash screen. Even worse, it might not even validate at all unless you reboot without startup-sequence and wait (often for a long time) for the discdoctor to finish. This has been a problem since old classic days, and I think it is time for the discdoctor to a) become verbose and tell the user, what is happening and b) for system boot to wait until the discdoctor finishes before continuing the boot process. Anything less is going to break the user experience.
Confirmed it here, check amigaworld.net thread. It's hard to reproduce.
Yes, I thought the problem was totally reproducable but when I added a test program to my WBStartup the problem seemed to disappear. When I removed the test program, the problem returned. Somehow the number or type of files in WBStartup seems to affect the bug. Thanks for confirming.
2) The discdoctor (or whatever it is called nowadays)!
The disk validator - it's built in into FFS (and only used/useful there).
Quote:
When a program (for instance Quake 3) crashes in the middle of something with files open, then the disc will be unvalidated at reboot and the discdoctor will initiate at boot time. This might _also_ hang up the machine at the splash screen. Even worse, it might not even validate at all unless you reboot without startup-sequence and wait (often for a long time) for the discdoctor to finish.
I believe this happens when something tries to write to the disk while it is validating. For me, that something is often TurboPrefs (TurboPrint) trying to write its prefs to Work: (where my TP installation lives). I've been trying to catch some debug output from this situation for a while.
PS: By the way, you can add WAITFORVALIDATE to your SetPatch command in your Startup-Sequence, that should keep the startup from proceeding until the disk has finished validating.
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
Some of the Prefs editors open their ASL requesters using the default requester position and size (as set in ASL prefs). Others use some custom values. I think all system components should respect the ASL prefs and use values from there.
@Rigo On AW (here), Denial have found some bug (looks like) related to GR itself: Quote:
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.
His conclusion is wrong. The state of the system after any crash is not guaranteed, and GrimReaper cannot affect that unfortunately. The endless stream of "insanity" errors in his test case is the cause of a corrupted memory list, not GrimReaper.
Killing a process which is in an undetermined state (and may have corrupted system lists) can have all sorts of undesirable effects.
Try calling RemTask() once the GrimReaper appears and you'll probably get the same stream of DSI's.
In short, if a program crashes, "Continue" and "Kill" are in no means guaranteed to work. This is the problem of a simgle address space, and the corruption to other tasks space that it can cause.
Simon
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
@Rigo Other user say on that: "How is that test program supposed to have corrupted the memory list? It does nothing but a *read* from address *zero*...."
I admit I have not programmed on the Amiga, but I understand your reply in general. And I agree that the purpose of GR is different than e.g. memguard, and that by the time it launches it is too late for any guarantees.
However, I don't understand how his specific simplistic program that only reads from 0x0 can cause such non-recoverable conditions, whether the read is allowed to happen or not. How is any program ever killable if this example is not? I guess I am also assuming that if he just ignored the GR window and did none of Kill/Reboot/Continue that the rest of the system and applications would keep running just fine. What am I missing here... is it some of the invisible auto-library stuff?
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.
Simon
Edited by Rigo on 2010/7/12 17:11:18
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
Well, regardless of whether there is bug in GrimReaper or not, I cannot reproduce the effect described with this program here.
I can even continue and the program exits normally.
So perhaps whatever is causing the described problem has since been addressed directly, or indirectly.
EDIT: See above for further info.
Simon
Edited by Rigo on 2010/7/12 17:58:12
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
Well, regardless of whether there is bug in GrimReaper or not, I cannot reproduce the effect described with this program here.
I can even continue and the program exits normally.
So perhaps whatever is causing the described problem has since been addressed directly, or indirectly.
i also tested it.
1. on my normal system grim reaper crashes 2. on a clean system (us4.1upd2 installed - nothing else) grim reaper works fine! 3. on my normal system, bootet with no-startup, loadwb "manually xeceuted" and no wbstartup at all, grim reaper also crashes!
i don't wonder about 1+2. but 3 is strange, imho. maybe i'll investigate further what exactly causes the reaper to crash.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
