Re: abnormal thread termination

[David Chisnall]

On 13 Jul 2015, at 10:32, Richard Frith-Macdonald <address@hidden> wrote:
> 
>> 
>> On 13 Jul 2015, at 09:57, David Chisnall <address@hidden> wrote:
>> 
>> On 10 Jul 2015, at 20:18, Riccardo Mottola <address@hidden> wrote:
>>> 
>>> Hi,
>>> 
>>> I detach a thread "normally" with:
>>> 
>>> [updateButton setEnabled:NO];
>>> [NSThread detachNewThreadSelector:@selector(updateData:) toTarget:self 
>>> withObject:nil];
>>> 
>>> It executes everything as expected, but I continuously get:
>>> WARNING thread 0x2c63c1a8 terminated without calling +exit!
>>> 
>>> I have done something similar with other threads and I don't get this 
>>> error. What could be happening? Some sort of premature exit? It executes up 
>>> to the last statement.
>> 
>> This message also appears for threads that are not created with NSThread, 
>> which is quite annoying.  I use some of the C++11 threading support for some 
>> worker threads and I get a message when they exit.
> 
> This message indicates a bug in the program as far as I can tell from looking 
> at the source;
> 
> It’s generated by the handler set by pthread_key_create() and should only be 
> called if the thread exits while the thread-specific data associate with the 
> key (ie the NSThread object) is non-null.
> 
> When a thread is detached by NSThread, it runs a method and calls +exit when 
> the method completes, and +exit destroys the NSThread object and sets the 
> thread-specific data to null.
> When a non-gnustep thread is used for gnustep code, there are two functions 
> provided to register/deregister it (and the latter similarly destroys the 
> NSThread instance and nulls-out the thread-specific variable).
> 
> So seeing the message means that a thread has somehow exited without cleaning 
> up its gnustep related thread-specific data (thus leaking an NSThread 
> instance and a presumably other related objects).
> 
> I don’t see how that can happen other than by an application level bug (ie 
> some code in that thread calls pthread_exit() or something similar).
> 
> Of course, I may have missed spotting some race condition or logic error in 
> the code … 

Hmm, I wasn’t quite correct - it does call Objective-C stuff, but:

- There is no autorelease pool on the thread
- There are no references to NSThread
- All memory management is handled by ARC / C++

In this case, NSThread should not need to be used - if it does internally, then 
it should clean itself up on thread exit.  The same code works fine on OS X 
without any warnings.

David




-- Sent from my Difference Engine