Re[2]: [Gc] pthread_suspend failed - using pthread_exit(0)

[Ivan Maidanski]

Hi Paul,

I assume you are using the latest GC alpha release (or Git snapshot).

Yes, the problem exists as we don't expect that application calls pthread_exit for the primordial thread.
I think we should handle this by redirecting pthread_exit (for now pthread_exit is redirected only on linux for handling cancellation).

It would be good if you could propose a draft patch fixing this.

Note also, that the code shown bellow is not used unless you call GC_use_threads_discovery at startup (this may workaround the bug):

>     kern_result = thread_suspend(thread);
>     if (kern_result != KERN_SUCCESS) {
>       /* The thread may have quit since the thread_threads() call we  */
>       /* mark already suspended so it's not dealt with anymore later. */
>       if (!found)
>         GC_mach_threads[GC_mach_threads_count++].already_suspended = TRUE;
>       continue;
>     }

Regards.

18 09 2011, 03:52 Bruce Hoult <bruce at hoult.org>:
> On Thu, Aug 18, 2011 at 5:30 AM, Paul Poley <baylorpaul at gmail.com> wrote:
> > Using the Boehm garbage collector, I have recently run into a case where I
> > am getting an error "pthread_suspend failed" using OSX.
> > At that point, the main thread had called pthread_exit(0), so as not to
> > terminate while other threads are still running.  Shortly afterwords, the
> > error occurs.
> > If I wait on a condition (in order to keep the process alive), rather than
> > invoke pthread_exit(0), the error does not occur.
> 
> If you look in darwin_stop_world.c you can find in GC_stop_world():
> 
>       for (p = GC_threads[i]; p != NULL; p = p->next) {
>         if ((p->flags & FINISHED) == 0 && !p->thread_blocked &&
>              p->stop_info.mach_thread != my_thread) {
> 
>           kern_result = thread_suspend(p->stop_info.mach_thread);
>           if (kern_result != KERN_SUCCESS)
>             ABORT("thread_suspend failed");
>         }
>       }
> 
> The code tries to avoid calling thread_suspend() in situations in
> which it will fail (or for the current thread), but perhaps there is
> another case that can be added.
> 
> In GC_suspend_thread_list() it is assumed that an error on a call to
> thread_suspend() means the thread has been suspended (or terminated?)
> since the threads were last enumerated and the error is basically
> ignored.
> 
>     kern_result = thread_suspend(thread);
>     if (kern_result != KERN_SUCCESS) {
>       /* The thread may have quit since the thread_threads() call we  */
>       /* mark already suspended so it's not dealt with anymore later. */
>       if (!found)
>         GC_mach_threads[GC_mach_threads_count++].already_suspended = TRUE;
>       continue;
>     }
> 
> Perhaps another test can  be added in GC_stop_world() that will detect
> the situation where the thread has called pthread_exit(0) and avoid
> the error.
> 
> Or perhaps it's safe to simply ignore the error, as in GC_suspend_thread_list().
> 
> Or perhaps #dontdothat.
> 
> I don't know enough about Darwin to say, but maybe someone else here
> does, given the above code fragments.
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>