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

[Philippe Roussel]

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 ?

> 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 ?

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

> #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