Hi, Curtis L. Olson schrieb: [SNIP]
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.
Thanks, that was the advice I needed. :-) Heh, two things I didn't think of: 1. I had checked whether I was setting ulimits, but I hadn't checked whether fgfs-construct itself is setting ulimits. I found a statement limiting CPU usage to 120s. This matches the fact that the generation was always aborted after about 2mins. 2. I expected SIGXCPU signals from the Linux kernel, which were not sent and thus I ruled out CPU-rlimits. However, SIGXCPU is only sent if the current limit and the hard limit differ. In case of fgfs-construct both the current and the hard limit are set to 120s. The generation is on the go and I'll probably release _two_ versions of the scenery this evening (UTC+2) - one with all the backstreets and one without. Ralf _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
