I run FG today successfully both with the gdb script and directly through the launcher. On both occasions I used the 777 aircraft. The gdb output does not indicate any major problem except the following:
Nasal runtime error: No such member: set_radio_mode
at /sim/gui/dialogs/radios/dialog/group[2]/button[3]/binding[3], line 1
And on exit:
Thread 23 "fgfs" received signal SIG32, Real-time event 32.
My puzzlement is why I have such inconsistency with FG, one minute in heaven and the next in the deep freeze. To be clear, when a freeze happens it is practically total. Everything stops: the clock, the keyboard, the mouse, any background jobs. So I can never use tools like top, htop, etc to check on the system status. What I tend to do is:
- run FG with the command "cpulimit -k -z -l 195 -- /usr/bin/fgfs $options" so that it will automatically be killed if the CPU demand exceeds 195%
- set up a terminal with the pre-typed command "pkill fgfs" and put the focus on it in case I still have a chance of killing it before it enters into the deep freeze
If either to this precautions fail, then I have to do a kernel reboot of if I am lucky I can kill the whole desktop with Ctrl+Sight+Backspace.
Something that might be relevant is that the freeze happens just before the plane appears or (less frequently) just before landing (nearing touchdown). Some planes can trigger a freeze or crash on a sound event (e.g. Mil-Mi-24). The Mirage-2000 is impossible to use on my system since it requires too much computing power.
I suspect one of the following to be causing the problem:
1. Memory: I actually have 4x1G memory with 13G of swap space. Could it be that I have too much swap vis-a-vis physical memory? But why the inconsistent performance?
2. Graphics driver: My latest success came from running FG on a non-compositing desktop (WindowMaker). Yesterday's freezes were on KDE Plasma. So could FG be clashing with the desktop for the graphics accelerator?
3. Sound: I use pulseaudio, but I am not sure it FG cares about that. On some freezes, the sounds continues in the background (as a loop) whilst all else is frozen. However, mostly the sound is not available during the freeze.
4. osgPlugins: Only based on my suspicions from old logs years ago when it used to produce database errors.
This setup is the same for all other high-intensity applications. The difference is consistency. If I build Chromium for example, I know that the system is will freeze around the 2/3rd mark for ~4 hours, so I can plan for it. The symptoms are the same as with the FG freeze. Incidentally, I don't allow a 4 hour freeze with FG because a few years ago my old motherboard was literally melted by FG when I forgot to kill it and went out on an errand.