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? > regards, > iustin > Regards, BenBE.
signature.asc
Description: OpenPGP digital signature