Bug 136073

Summary:	Memory never released when recording multitrack CDs
Product:	[Fedora] Fedora	Reporter:	Jean Francois Martinez <jfm512>
Component:	kernel	Assignee:	Dave Jones <davej>
Status:	CLOSED ERRATA	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	2	CC:	pfrields, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-11-27 21:35:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jean Francois Martinez 2004-10-17 15:08:08 UTC

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

Comment 1 Jean Francois Martinez 2004-10-19 13:50:08 UTC

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 05:17:15 UTC

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 19:22:48 UTC

It looks like 2.6.9 doesn't have this bug.