Ralf Gerlich wrote:
Hi,
Alex Perry schrieb:
Try watching your virtual memory usage and see whether you're hitting
the 2GB (or 3GB) limit within that process. If you are, it is worth
patching TerraGear until it runs cleanly on all 64 bit architectures.
If it isn't a memory problem, we can stick with the 32 bit for now.
I already had thought about that. I have Pentium-M with 512MB of RAM
and a 1GB swap-partition. Interestingly fgfs-construct does not even
get the 512MB filled up - with lots of daemons and stuff using up
memory in the background.
Even more interestingly, when I run an strace on the fgfs-construct
process, I see that the process is eventually SIGKILLed. I suspected
that this is some kind of resource control on the side of the Linux
kernel, which may KILL your process if it's using up too much memory
of CPU time. However, a SIGKILL for CPU time excess is always
preceeded by a SIGXCPU, which I cannot see in the strace-log. In
addition, 'ulimit' reports that the CPU usage limit is 'unlimited'.
An out-of-memory-kill should - according to the kernel source - be
accompanied with a message to the console or the kernel logs, and I
can't see any such message.
I have even stopped all background processes I could, effectively
putting my machine to single-user-mode, in order to rule out any other
processes being so rude as to kill my scenery construction process.
Unfortunately, that didn't help: The kill did still occur.
I tried to find out whether there was some specific point at which the
process is killed - perhaps there is some correlation with a previous
action - using nested intervals and as few as possible test printouts
in order not to modify the time-related behaviour of the code too
much. However the actual point in the code where the kill occurred
jumped as soon as I moved a printout marker from one place to another
and the places I observed did not seem to be related to the kill in
any way.
I'll try running the construction on a different computer.
It's been a while, but scan the fgfs-construct code for some sort of
ulimit checking built into the code. I seem to recall there was some
code there that would cause the process to self destruct if it sensed it
was taking too long or consuming too much memory? This is useful in the
parallel build framework so that an infinite loop (our delauney
triangulator and polygon clipping routines can go degenerate at times)
doesn't derail the whole build. The thresholds may need to be tweaked
or even eliminated.
Curt.
--
Curtis Olson http://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________
Flightgear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
