Re: libobjc threads leak?

[Alex Perez]

Larry Campbell wrote:
> I just switched from gcc 2.95.x, where the GNUstep dox say I must use 
> gnustep-objc, to gcc 3.3 where they say the built-in libobjc works fine. 
> But it doesn't. It leaks threads, so eventually your program crashes in 
> objc_detach_thread. The reason is that in gcc's libobjc, threads are 
> created joinable, so when they exit they hang around forever waiting to 
> be joined.

If you're sure about this, I implore you to please file a bug ASAP. if 
you're lucky, it will get fixed in time for the GCC4 release. I'm sure 
Andrew *will* address it, as soon as he sees your report, which you may 
have already filed.

> In gthr-posix.h:
>
>   if (!(pthread_create (&new_thread_handle, NULL, (void *) func, arg)))
>
> the second argument to pthread_create is NULL, which means default 
> attributes, which on linux 2.4 I believe means the threads are joinable, 
> not detached. Now it looks like someone thought about this a bit because 
> in the same gthr-posix.h there is a variable called _objc_thread_attribs 
> initialized thusly:
>
>           /* The normal default detach state for threads is
>            * PTHREAD_CREATE_JOINABLE which causes threads to not die
>            * when you think they should.  */
>           if (pthread_attr_init (&_objc_thread_attribs) == 0
>               && pthread_attr_setdetachstate (&_objc_thread_attribs,
>                                               PTHREAD_CREATE_DETACHED) 
> == 0)
>             return 0;
>
> but _objc_thread_attribs, which you would think would be used as 
> pthread_create's second argument, is in fact never used at all!
>
> Note that the thr-posix.c in gnustep-objc has nearly identical code that 
> works -- it remembers to pass the _objc_thread_attribs in:
>
>   if (!(pthread_create(&new_thread_handle, &_objc_thread_attribs,
>                        (void *)func, arg)))
>
> So, am I missing something here, or is gcc's built-in libobjc totally 
> useless for multithreaded programs?