[Pkg-mc-devel] Bug#556922: Console resize freezes mc causing system crash/hang
BenBE at geshi.org
Wed Dec 2 19:26:54 UTC 2009
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.
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Pkg-mc-devel