Stephen Bailey writes: > > Hi. > > I just really hosed a Linux machine by running a ROOT job that > apparently filled up memory. After the ROOT job died with > > Fatal in <operator new>: storage exhausted > aborting > > The machine was rendered incapacitated, with all commands producing > segmentation violations and eventually the system killing the > window manager and reporting "unable to load interpreter" for any > further command attempts. Nothing short of a reboot assuaged its > distress. This is the second time that this has happened to me with > various ROOT jobs. > > The obvious answer is that I have a memory leak, and I did find one > that put around 5000 TMinuit objects in memory before the crash. > But no other call to new in my code is within the main event loop. > > What concerns me most is that ROOT/CINT can do this. I'm not used to > being able to crash Linux so severly. On some level, this seems to > be a Linux bug for it to allow me/ROOT to crash it. If anyone has > experience with this style of crash, please let me know. I can > provide a tarball of my program, etc. as needed. I haven't been > able to regularly repeat the crash -- usually it just ends with > > *** Break *** segmentation violation > > > Warning in <TH1::Build>: Replacing existing histogram: h1 > Fatal in <operator new>: storage exhausted > aborting > > But doesn't actually completely hang the system. Advice or insight > on making my system more robust would be appreciated. hi Stephen, try adding Root.MemStat: 1 Root.ObjectStat: 1 to your .rootrc and calling gObjectTable->Print() say each 100 events in your main loop. In case of TObject memory leak this would tell you where the leak is happening. -pasha
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:27 MET