Description of problem: Memory never released when recording multitrack CDs, swapping is so severe it ruins the CD and only way to recover is by hitting the reset button Version-Release number of selected component (if applicable): 2.6.8-1.521 How reproducible: Allways Steps to Reproduce: 1. If your machine has over 512M then reboot with mem=512m 2. Get a few wav files and try to make an audio CD of them 3. Do a few "free" and "ps" while recording is in progress Actual results: Memory usage grows and grows for several hundreds of megs, machine enters very heavy swapping becomes competely unresponsive and at one point the only way to regain control is to use the reset button. Expected results: A nice, clean audioCD. :-) Additional info: This is specific to kernel 2.6.8-1.521. With kernel 2.6.6-1.435.2.3 (memory usage doesn't grow and recording multitrack CDs works fine). It happens whatever mode of CD recording you try: DAO, TAO or Raw. If you use SCSI emulation or IDE-mode recording. It doesn't happen with monotrack CDs like when you record an ISO image On kernel 2.6.8, free shows a heavy increase in memory usage (coherent with machine behavior) but ps doesn't show any process using abnormal amounts of memory or an abnormal number of page faults. Also if you cancel when machine has become very slow but still not unusable then everything is very, very, very slow to restart as if large numbers of pages had remained locked and hadn't been freed when cdrecord ended. Finally I noticed that growth of memory usage seems to be roughly equal to the amount of data who has been read by cdrecord
I have raised severity to high due to concerns that aother applications could be hit by 2.6.8s problem with memory management. If it only affects cdrecord then it is a small problem. Also I failed to mention that free does not show a decrease of memory usage after recording ends (this in addition that after recording ends the machine shows the symptoms of a box who has far too little memory when it should have over 400M free)
I thought the leaked memory could be shared memory but ipcs shows nothing. After returning to runlevel and performed an ipcclean I had zero segments of shared memory and only init and /bin/sh running but memory usage was over 300 Megs.
It looks like 2.6.9 doesn't have this bug.