I’m getting a segmentation fault at the beginning of my ROOT job (before any events are processed). When trying to track this down with gdb I run out of virtual memory:
utils.c:1014: gdb-internal-error: virtual memory exhausted.
What happens at the beginning of your job? Are many shared libs being loaded, creating many objects, etc? Check with vmstat or xosview what is going on.
[quote=“rdm”]What happens at the beginning of your job? Are many shared libs being loaded, creating many objects, etc? Check with vmstat or xosview what is going on.
Actually, not that many things are loaded in the memory (the RAM jumps up by ~80 MB on a 1 GB RAM PC). The seg. fault is pretty much reproducible (I’ve run the code about 10 times, I think I failed to get a crash only once ), even though it sometimes occurs a little later (after a few events have been processed).
This may be a rare problem in my code: I’ve run/submitted 62 jobs (a total of 3.5 M events), 61 jobs went through fine, this one refuses to cooperate. Or, it could be a problem with the input file. The problem is that when I try to track this down with gdb I run out of memory (gdb gets killed, at one instance my Linux box had to be rebooted…). So, I’m out of ideas at this point…
I found the problem causing the segmentation fault (which was in my code). I had to migrate the code to another PC with 2 GB RAM in order to run gdb.
Still surprised though that gdb needs 1.8 GB of RAM to track down a problem in a piece of code that is happy with 80 MB of RAM.
Oh well… (I must be off topic by now )
OK, off-topic, but, I have noticed this too: gdb needing excessive amounts of memory. Current versions of D0 code come with an older version of gdb, so you could try getting a newer one (how about “unsetup gdb”, depending on what system you’re on). It worked for me (RH Linux 7.3).