MorphOS froze three times on me in the last couple of days:

- first time, I don't exactly remember what I was doing
- second time, this morning, during the boot, the boot screen just stayed forever
- third time, just minutes ago, I was dragging and dropping a file

Questions:

- if I start reporting these as bugs, is there any log file I should include so you can somwhow at least try to decypher what happened?
- is there a magical combination of keys or something which can bring up some kind of task-manager so I can see what process is the offending one and kill it?
- if not, is there a way to include that as a feature?

YOU are using it too much!

> is there a magical combination of keys or something which can bring
> up some kind of task-manager so I can see what process is the offending one

TaskManager application is in Sys:Utilities.

> TaskManager application is in Sys:Utilities.

How is it gonna behave if the system freezes? Does it show what process is frozen? Does it have higher priority than everything else so I can still break the process or is it going to be unresponsive as the rest of the system?

Will try all this the next time it happens. I guess first thing is to have it running all the time (that's why I asked about a combination of keys, something like Windows has).

Do you maybe know anything about which logs might be relevant and where they are?

> How is it gonna behave if the system freezes?

If the whole system freezes so that it is effectively halted, you can only reboot.

> Does it show what process is frozen?

Yes.

> Does it have higher priority than everything else so I can still break the
> process or is it going to be unresponsive as the rest of the system?

By default the TaskManager runs with a priority of 1. To see how that compares to other system tasks you just have to open TaskManager. The third column shows the tasks' priority. If a stuck task is eating up CPU time the TaskManager will be as slow as any other program running with the same priority.

> Do you maybe know anything about which logs might be relevant and
> where they are?

------------------------------
Q: I encountered a bug. After reporting it, I was asked to use the ramdebug boot parameter and send a debug log file. What do I need to do exactly?
A: Enter 'getramdebuglog ram:morphos.log' in a shell window and send the newly created file named morphos.log, which is to be found in your Ram Disk, to the developer.
[...]
Q: Can the ramdebug be made reset resident?
A: You can use the additional boot arguments rds (ramdebugsize) and rdo (ramdebugoffset) to modify internal settings. Ramdebug does not survive a reset when it is located in the first 32MB of ram (i.e. it will be overwritten by the firmware)
Example:
> boot boot.img ramdebug rdo=33555456
If you type the above, this will result in the Ramdebug log surviving a reset on Pegasos computers by moving its buffer outside the first 32MB of RAM. Of course, this implies that sufficient memory is available to do so.
------------------------------
http://www.morphos-team.net/faq.html

OK I remember seeing this now. IMHO, this should be more streamlined so that any newbie can immediatelly report crashes and freezes, otherwise you might lose a great opportunity to see some rare bugs in action.

I will try to follow the instructions but:

- do the exact the same steps apply in my case? (random freezes)
- do they apply to Mac Mini too?
- since I did not execute any commands, does that mean that the log information is lost forever since it was not made it resident and that I need to execute those commands, wait for another freeze and only then send the log?

Basically, the holy grail here, and therefore a feature request , is to detect any unclean shutdown (hard reset) and, on the very next startup, ask user whether to automatically file a bug report and automatically collect all the logs like now you do for the sysconfig. I think this would result with some interesting logs to play with... Just my humble opinion.

if I start reporting these as bugs

The first thing before submitting a bug is to make it reproducable, so a sequence of events making the bug happening everytime should be determined.

[ Edited by Krashan on 2010/1/18 7:08 ]

> make it reproducable

QA 101, of course. However, the most interesting and the deepest bugs are sometimes these edge cases when nobody knows what happened but the logs don't lie

Unfortunately on systems without separate address spaces for processes (like MorphOS is), such random bugs are usually caused by 3-rd party applications trashing memory.

And when you take new 3rd party progams in use, it's good to check ramdebuglog few times when using it (even though it seems to work ok) to see it doesn't do anything suspicious. Because badly behaving programs usually hit in the log before crashing, logs obtained before any possible system lockup can be useful.

The easiest way to see the log is to enable debug sbar module and click "show log" in it. It doesn't harm to check it once a while in normal use either. If there's been hit, you'll notice it. Log will be muuuch bigger than normally then :)

The system should also be configured to pop up a window everytime an illegal access is detected (if the system is still alive to do it...).

@Krashan: got it: No memory protection (with all pros and cons) makes harder to point fingers to apps.

@jPV: got it: It's good to be preemptive and check upfront.

@Henes:
> The system should also be configured to pop up a window
> everytime an illegal access is detected (if the system is still alive to do it...).

Are you saying to *me* to configure it like this (if so, I will dig tonight for this setting... arguably maybe it should behave by default like this) or are you making a mental note to *yourself* to include this in a future MorphOS version?

To you, of course :)
I have no idea if the log server if enabled by default. If not, you can enable it in your boot line command (i.e. boot bootimgpath logserver). You can know all other arguments using the usual "?" btw.

Edit: seems it is still not enabled and users miss all bugs catched by the os... Lame.


[ Edited by Henes on 2010/1/19 1:19 ]

Without opening a new toipic MorphOS freezes....
After the error block surprise, repaired with greta SFS Doctor prog, after a bunch of resets (!!) MorphOS starts: first trying to boot and when this happens "Ambient - Illegal thread" error, "Public Screen Manager - Illegal instruction". Then booting in normal Ambient screen with nothing beeing selectable (icons, bar and so on). I only tried to open debug log and this made Ambient totally freeze.
I guess it's hard disk problem. I hope not mobo...
Tomorrow I will try: a) changing hard disk; b) serial debug.
C) ...installing MorphOS on PowerMac?!?... ahem...