Vorbis dev - May 2001 - Possible fix for bug #14 (ogg123 -b memory leak)

Hi all,

Browsing through the bug database, I was able to reproduce #14.  Briefly, 
when I run, for example:
        ogg123 -b 8000 test1.ogg test2.ogg test1.ogg [...]
where test1.ogg and test2.ogg have different bitrates or numbers of 
channels (that is important), ogg123's memory usage continuously 
increases as each new song is played.

I think I've tracked down the bug to the use of shared memory in the 
buffer code.  It appears that shmdt() needs to be called on the segment 
each time the buffer is shut down.  The following patch fixes the problem 
for me. 

Only the second call seems to be necessary, but I included the first for 
completeness.  Also, I'm not sure I put the calls in the optimal places, 
so if someone could confirm that the fix is correct, it would be appreciated.

-- Wil

Index: buffer.c
==================================================================RCS file:
/usr/local/cvsroot/vorbis-tools/ogg123/buffer.c,v
retrieving revision 1.4
diff -u -r1.4 buffer.c
--- buffer.c	2001/03/22 05:43:48	1.4
+++ buffer.c	2001/05/11 02:55:08
@@ -59,6 +59,7 @@
    }
   buf->status = 0;
   write (buf->fds[1], "2", 1);
+  shmdt (buf);
   _exit(0);
 }
 
@@ -173,5 +174,6 @@
       tv.tv_usec = 0;
       select (0, NULL, NULL, NULL, &tv);
     } 
+  shmdt (buf);
 }
      

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Fri, May 11, 2001 at 12:39:31AM -0400, William T. Mahan
wrote:
> Only the second call seems to be necessary, but I included the first for 
> completeness.  Also, I'm not sure I put the calls in the optimal
places,
> so if someone could confirm that the fix is correct, it would be
appreciated.
The first call is indeed unnecessary; when the process exits
(_exit(0)), all shared memory segments are detached. But the second
call was indeed an error on my part; it worked fine when the buffer
was never freed until exit, but when multiple songs with different
bitrates came into play, the cleanest way to deal with the problem was
to flush and shutdown the buffer entirely each time (because the
devices list otherwise would not get updated; TODO Ken, make devices_t
shared in the shared memory segment and don't kill the buffer every
time).

Or (to all...) is pthreads portable enough to make the writer a thread
instead of a process? (well on Linux at least it would still be
another process, but sharing memory so we don't have to deal with this
sysv shm stuff anymore). Am I correct in assuming that pthreads is
more portable than sysv shared memory? Because if so, I'll dust off
the pthreads manpages and go clean up the buffer mess.


-- 
Kenneth Arnold <ken@arnoldnet.net> / kcarnold / Linux user #180115
http://arnoldnet.net/~kcarnold/



<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/octet-stream
Size: 233 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20010512/9122747e/part-0001.obj