Crashing Linux by filling memory

From: Pasha Murat (murat@cdfsga.fnal.gov)
Date: Wed Jan 06 1999 - 04:55:06 MET


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