[Gc] On cancellation, GC_thread_exit_proc is never
called (and cancellation in general)
hans.boehm at hp.com
Thu Apr 1 15:07:49 PST 2010
I really appreciate the work in tracking down this problem. Unfortunately, I'm less enthusiastic about the patch. The patch seems to rely on gcc internals that could change. And I'm not sure that GC_thread_exit_proc() will always be invoked last. Playing with gcc internal macros seems unpleasant, though it may turn out to be the only solution.
If I look at the gcc man page, e.g. https://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Code-Gen-Options.html#Code-Gen-Options, there is no hint that code compiled with and without -fexceptions is incompatible. By contrast, there are such warnings for several other options in that section. I would post a summary of the problem to the gcc list, and see if they can suggest something. At the moment this looks more like a gcc problem to me than a garbage collector issue.
If we don't get a better answer there, and if it works, I think a better fix is to pull GC_inner_start_routine out into a separate file that isn't compiled with -fexceptions. It's usually good to specify -fexceptions in case the out-of-memory callback ends up being a C++ routine that throws an exception, which is a very reasonable thing for it to do. But that should work without unwinding through GC_inner_start_routine.
Unfortunately thread cancellation is once again turning into a can of worms. I've so far also been unable to get a very authoritative answer from the Posix folks about the Solaris (and possibly Linux & ...) issue of disabling signal delivery while a thread is exiting.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Thursday, April 01, 2010 11:35 AM
> To: gc at napali.hpl.hp.com
> Subject: Re: [Gc] On cancellation, GC_thread_exit_proc is
> never called
> Wed, 31 Mar 2010 10:02:58 +0900 NIIBE Yutaka <gniibe at fsij.org>:
> > Ivan Maidanski wrote:
> > > Tue, 30 Mar 2010 13:48:08 +0900 NIIBE Yutaka <gniibe at fsij.org>:
> > >
> > > If this is a GCC-specific issue then, I think, "&&
> defined(__GNUC__)" should be added to the patch.
> > [...]
> > >> In case of -fexceptions, __cleanup__ attribute is
> used and it is
> > >> recorded in the .eh_frame section.
> > >> Without option of -fexceptions, it is registered by
> > >> __pthread_register_cancel.
> Hans -
> Any comments? (Does it look ok to apply?)
> > Yes, this is a GCC specific issue. In pthread.h, we see:
> > #if defined __GNUC__ && defined __EXCEPTIONS
> > for pthread_cleanup_push with __cleanup__ attribute.
> > That is, the problem of never called GC_thread_exit_proc
> occurs only
> > if gcc -fexceptions is used.
> > So, here is second try which has better ifdef condition
> with __GNUC__.
> > Index: include/gc_config_macros.h
> > ===================================================================
> > RCS file: /cvsroot/bdwgc/bdwgc/include/gc_config_macros.h,v
> > retrieving revision 1.22
> > diff -u -r1.22 gc_config_macros.h
> > --- include/gc_config_macros.h 20 Oct 2009 21:27:26
> -0000 1.22
> > +++ include/gc_config_macros.h 31 Mar 2010 00:57:58 -0000
> > @@ -139,6 +139,20 @@
> > # define _REENTRANT
> > #endif
> > +# if defined(__GNUC__) && defined(GC_LINUX_THREADS)
> > + /* We undefine __EXCEPTIONS to avoid using __cleanup__
> attribute of GCC. */
> > + /*
> > + /* NPTL implementation of pthread_cleanup_push uses
> __cleanup__ attribute */
> > + /* when __EXCEPTIONS is defined (-fexceptions).
> > + /* Stack unwinding and cleanup with __cleanup__
> attributes works correctly */
> > + /* when everything is compiled with -fexceptions, but it
> is not the */
> > + /* requirement for this library users to use
> -fexceptions everywhere. */
> > + /*
> > + /* With __EXCEPTIONS undefined, cleanup routines are
> registered with */
> > + /* __pthread_register_cancel, which works any cases.
> > +# undef __EXCEPTIONS
> > +# endif
> > +
> > #define __GC
> > #if !defined(_WIN32_WCE) || defined(__GNUC__) # include <stddef.h>
> > --
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc