Crashing Linux by filling memory

Pasha Murat (murat@cdfsga.fnal.gov)
Tue, 5 Jan 1999 21:55:06 -0600 (CST)

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