Re: [Gap-dev-discuss] One more crasher in Cynthiune

[Sebastian Reitenbach]

On Monday, May 7, 2012 19:59 CEST, Philippe Roussel <address@hidden> wrote:

> Le 07/05/2012 19:31, Sebastian Reitenbach a écrit :
> > Hi,
> >
> > another crasher, now with your updated patch you just sent. But I think, 
> > its not caused by
> > the patch, I guess it must have been there before.
> >
> > How to reproduce:
> > 1. start one song playing.
> > 2. double click another song from the playlist while the other song still 
> > plays
> > 3. if not crash, repeat step two a couple of times
> >
> > The crash may not always happen, but can be on the third or fourth try
> > double clicking different songs from the playlist.
>
> Can you reproduce this with the Sndio bundle ?

Indeed, I can, backtrace looks the same. So probably a more general problem.


>
> > Since the AO threadLoop is involved, I already tried to put the lock before 
> > the line
> > like this:
> >
> >  [devlock lock];
> >  bufferSize = [parentPlayer readNextChunk: buffer
> >                                       withSize: DEFAULT_BUFFER_SIZE];
> >
> > but that did not helped here.
> >
> > Sebastian
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to thread 1028692]
> > 0x86066648 in memcpy (dst0=0x8362a8d4, src0=0x8362a8d5, length=0)
> >     at /usr/src/lib/libc/string/bcopy.c:91
> > 91      /usr/src/lib/libc/string/bcopy.c: No such file or directory.
> >         in /usr/src/lib/libc/string/bcopy.c
> > (gdb) bt
>
> Here length=0, could that be a problem in the MP3 bundle ?

I also see the lenght=0, but when I go to frame #1, and do a print
inputRemain I get 40959.

>
> Or maybe a race between the thread reading data and the main thread
> closing and opening file streams from which the data is read ?

Yes, I'd probably guess that. Since it says, that the buffer is out of bounds.
So it created a new buffer on a new place, and the old address may be void.

Sebastian


>
> > #0  0x86066648 in memcpy (dst0=0x8362a8d4, src0=0x8362a8d5, length=0)
> >     at /usr/src/lib/libc/string/bcopy.c:91
> > #1  0x8971a694 in calcInputRemain (stream=0x8362745c,
> >     iBuffer=0x8362a8d4 <Address 0x8362a8d4 out of bounds>) at MP3.m:120
> > #2  0x8971b168 in -[MP3 readNextChunk:withSize:] (self=0x83625008,
> >     _cmd=0x185b0ec, buffer=0x8a663030 "\001", bufferSize=8192) at MP3.m:536
> > #3  0x01815104 in -[Player readNextChunk:withSize:] (self=0x896cc0c8,
> >     _cmd=0x8a3b95b0, buffer=0x8a663030 "\001", bufferSize=8192) at 
> > Player.m:245
> > #4  0x8a3981e0 in -[AO threadLoop] (self=0x8a663008, _cmd=0x8a3b95d0)
> >     at ao.m:130
> > #5  0x822c7c80 in -[NSObject performSelector:withObject:] (self=0x8a663008,
> >     _cmd=0x825affac, aSelector=0x8a3b95d0, anObject=0x0) at NSObject.m:2010
> > #6  0x8235d53c in -[NSThread gnustep:base:user:main] (self=0x835d5388,
> >     _cmd=0x825affb4) at NSThread.m:741
> > #7  0x8235d7fc in nsthreadLauncher (thread=0x835d5388) at NSThread.m:807
> > #8  0x85f51258 in _rthread_start (v=Variable "v" is not available.
> > ) at /usr/src/lib/librthread/rthread.c:113
> > #9  0x85fe07f8 in __tfork_thread () from /usr/lib/libc.so.64.0
> > #10 0x85fe07f8 in __tfork_thread () from /usr/lib/libc.so.64.0
> > Previous frame identical to this frame (corrupt stack?)
> >
>
> Thanks,
> Philippe
>