Bug 136073 - Memory never released when recording multitrack CDs
Memory never released when recording multitrack CDs
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-10-17 11:08 EDT by Jean Francois Martinez
Modified: 2015-01-04 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-27 16:35:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jean Francois Martinez 2004-10-17 11:08:08 EDT
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):

How reproducible:

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
Comment 1 Jean Francois Martinez 2004-10-19 09:50:08 EDT
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)
Comment 2 Jean Francois Martinez 2004-10-21 01:17:15 EDT
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.
Comment 3 Jean Francois Martinez 2004-10-22 15:22:48 EDT
It looks like 2.6.9 doesn't have this bug.  

Note You need to log in before you can comment on or make changes to this bug.