Quote:

I don't remember. I have only older AROS builds. It's normal that an AROS app crashing causes AROS hosted itself to crash. When debugging (you normally need a AROS debug build) you always debug AROS itself as a whole by launching AROS hosted with gdb from Linux. Then when crash happens (if it's a hang you can use CTRL+Z in Linux shell where gdb is running to break into gdb) you can use "bt" to show backtrace. There are AROS custom gdb commands (from ".gdbinit" file): "thistask", "taskready", "taskwait", "bttask <taskaddress>" (to see what other tasks are doing at the moment), "semowner <semaphoreaddress>" (for deadlocks, if you see a task stuck in obtainsemaphore. To see which task currently owns sem). If backtraces show "??" instead of function names there are commands to load the symbols. "loadmods", "loadbt", "loadseg <address>", ...

As said I don't have recent AROS builds, so I don't know if it all still works (or works like that).

Even with no debug build of AROS (and app) you can still try running it through gdb and then do a "bt" and maybe "disassemble <address>". If the disassembly shows stuff like "xmm0" (SSE stuff) then you may have run into stack alignment incompatibility they created in Linux 32 bit x86 some years ago when they changed default stack alignment to 16 bytes. This breaks old code (or other code which ignores it) if that code calls into new 32 bit libraries (like libX11, libxcb for gfx functions calls like being done by AROS hosted X11 gfx driver) which rely on that 16 byte alignment. So if you are running a 64 bit Linux distribution and you are running into this easiest fix might be to recompile this problematic 32 bit libraries with "-mstackrealign" flag.

You probably get better answers/suggestions on AROS Exec, as I mostly just know how it was some years ago when I still used 32 bit Linux distribution and older AROS versions.