Re: Please test new NSLock implementation!

[David Chisnall]

Hi Philippe,

Thanks for the report.  It seems that the default behaviour of a  
pthread mutex is subtly different between FreeBSD and with glibc.   
Mutexes with no explicit attributes are error-checking on FreeBSD /  
Darwin, but not on Linux.  Given that the test is failing there, and  
not earlier, it seems that error-checking mutexes do work correctly if  
explicitly requested.  Hopefully this is fixed in r28599 - please let  
me know if that works for you.

There are two expected failures for that test.  OS X doesn't throw an  
exception in double-lock cases, it just logs a warning and deadlocks.   
The new code logs the warning but doesn't deadlock.  Possibly entering  
a deadlock state is better, because it forces people to fix their  
code, but I've left it as-is for now.

David

On 2 Sep 2009, at 15:22, Philippe Roussel wrote:

> Le mercredi 02 septembre 2009 à 14:12 +0100, David Chisnall a écrit :
> > Hi Everyone,
> >
> > I've just committed a new version of all of the NSLock family of
> > classes to GNUstep-base, and a slightly reworked NSThread.  Bugs in
> > this code have the potential to break any multithreaded applications,
> > so please test them on your favourite platform, with your favourite
> > applications.  And on platforms you hate with apps you can't stand,
> > for that matter.
>
> Hi David,
>
> I've just launched the testsuite used for the GNUstep testfarm and it
> stops on 'Testing base/NSLock/doubleLocking.m...'
>
> philou@woody:~/sources/gnustep-testfarm/testsuite$ strace -p 8645
> Process 8645 attached - interrupt to quit
> futex(0x89e70fc, FUTEX_WAIT_PRIVATE, 2, NULL
>
>
> (gdb) bt
> #0  0x4001e430 in __kernel_vsyscall ()
> #1  0x40363cf9 in __lll_lock_wait ()
> at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S: 
> 136
> #2  0x4035f129 in _L_lock_89 () from /lib/tls/i686/cmov/ 
> libpthread.so.0
> #3  0x4035ea32 in __pthread_mutex_lock (mutex=0x89e70fc) at
> pthread_mutex_lock.c:86
> #4  0x4018ad78 in -[NSCondition lock] (self=0x89e70c8,  
> _cmd=0x402eed80)
> at NSLock.m:226
> #5  0x4018a01b in -[NSConditionLock lock] (self=0x8a06780,
> _cmd=0x804b600) at NSLock.m:308
> #6  0x08049555 in main () at doubleLocking.m:26
>
> This is on linux ix686.
>
> Hope this helps,
> Philippe