Re[3]: [Gc] Re: Valgrind patch

Ivan Maidanski ivmai at
Fri Mar 12 05:29:02 PST 2010

Thu, 11 Mar 2010 04:17:42 -0600 письмо от No Itisnt <theseaisinhere at>:

>  I think I understand now. GC_get_stack_base is likely not used
> because it can provide an undesirably large value in non-threaded
> builds, as per the comment at about os_dep.c:1300.
> The attached patch will prefer pthread_attr_getstack on linux when
> available, via GC_get_stack_base. It will fallback to the other
> methods if pthread_getattr_np fails.

Ok. I've committed the patch (see attachment)) which should solve your problem. Use -D USE_GET_STACKBASE_FOR_MAIN (without it the behavior is unchanged). Does it work for you?

Hans -
what do you think about using pthread_attr_getstack() in GC_get_main_stack_base() by default for Linux with threads?

> > I find the phrase  Linux threads  confusing since that s the name of the
> > former thread library used on GNU/Linux.  It s not what you meant, is
> > it?
> No, sorry, I just meant builds on Linux with threads enabled.
> > Again, I don t think the kernel matters much here.  The use of
> >  __libc_stack_end  should be in #ifdef __GLIBC__ so that it will just
> > work on all GNU variants (currently GNU/Linux, GNU/Hurd, and
> > GNU/kFreeBSD).
> >
> > Also, /proc is the third method in this list, so it may be that it will
> > never be used in that list.  If that is the case, code that handles it
> > could be dropped altogether.
> The third case would be used when building on non-glibc linux systems.
> According to the comments, __libc_stack_end is improperly set under
> some conditions, so it is required even with glibc.
> ATTACHMENT: application/x-patch (valgrind5.patch)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bdwgc-ivmai-237.diff
Type: application/octet-stream
Size: 1183 bytes
Desc: not available
Url :

More information about the Gc mailing list