[Pkg-mc-devel] Bug#556922: Console resize freezes mc causing system crash/hang

[Iustin Pop]

On Wed, Dec 02, 2009 at 08:26:54PM +0100, Benny Baumann wrote:
> Am 01.12.2009 22:18, schrieb Iustin Pop:
> > On Wed, Nov 18, 2009 at 11:54:31AM +0100, Benny Baumann wrote:
> >   
> >> Package: mc
> >> Version: 2:4.6.2~git20080311-4
> >> Severity: critical
> >> Justification: breaks the whole system
> >>
> >> When running mc inside a screen session via SSH mc crashes as soon as you resize
> >> the window in which mc is displayed. When this error occures mc freezes and
> >> allocates memory in an endless loop in the background. Once system resources
> >> have been reached the entire system freezes. Sometimes (tested with a system
> >> with a Xen 3.2-1 hypervisor) this even might kernel-panic the hypervisor.
> >>
> >> Steps to verify (the ones that worked for me):
> >> - Fire up a DomU with Xen (3.2-1)
> >> - Connect to that DomU by SSH
> >> - apt-get install screen mc
> >> - Fire up new screen session or take over an existing with screen -d -RR
> >> - In that screen session start mc
> >> - Resize the Window of the screen session
> >> - MC freezes (now wait a few seconds for MC to fill up the memory)
> >> --> The system completely hangs, probably with Kernel Panic
> >>
> >> On the step where mc starts to hang have a view on top or htop regarding mc's
> >> memory usage which suddently increases rapidly. If you kill mc fast enough
> >> (before it reaches the maximum RAM available) no crash of the VM happens.
> >>     
> > This doesn't happen anymore with the unstable version (2:4.7.0-pre1-3).
> > Could you try testing that and see if it indeed works for you (maybe by
> > building it for lenny?)
> >   
> Might be a bit complicated as both systems I could test it on are
> running at most testing, which doesn't include 2:4.7.0-pre1-3 yet AFAIK.
> As both systems are production updating might take a bit for me to test
> - especially because of the system crash involved in this. Will have a
> look at this though and comment back.

Sounds good, thanks.

> > While this is indeed unpleasant, the fact that mc eats a lot of memory
> > should not kill the whole system, and is more likely a wrong system
> > configuration, I think.
> >   
> More or less a default Xen configuration with one hypervisor (only few
> RAM, but swapspace) and 2 DomUs which split the remaining RAM between
> them. So really no rocket-science in that configuration. The system
> crash on Xen comes as soon as MC reaches full RAM reserved for the DomU
> (unswapped) memory size which results in a kernel panic (full Dom0
> reboot). Updating Xen doesn't work (The maschine/Dom0 won't boot with
> Xen 3.4 installed). Maybe FW for the Xen guys?

Ah, I was more referring to the unlimited memory size permissions for
user processes. Granted, the VM shouldn't crash, it should just go into
OOM and kill the offending process, but Xen is quirky sometimes.

So ignoring for the moment the Xen problem, the issue is mc getting out
of memory completely. I just tested the exact mc version in a Lenny
installation (a VM running under VirtualBox) and I can't reproduce the
issue.

Could you please try:

- before starting mc, run "ulimit -m 131072" which should limit the
  memory usage at 128MB, start mc and do the resize, and see if mc dies
  with out of memory?

If that is so, then we can be sure mc is the problem (I know it's been
verified with top, but just the same, let's see if ulimit indeed fixes
the problem) and maybe look at some traces.

regards,
iustin