Red Hat Bugzilla – Bug 136073
Memory never released when recording multitrack CDs
Last modified: 2015-01-04 17:10:46 EST
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):
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
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.
A nice, clean audioCD. :-)
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.