This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
RE: [PATCH] Fix pthread_getattr_np call in boehm-gc
- From: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: "Andrew Haley" <aph-gcc at littlepinkcloud dot COM>, "Jakub Jelinek" <jakub at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, <java-patches at gcc dot gnu dot org>
- Date: Fri, 22 Jun 2007 19:07:58 -0000
- Subject: RE: [PATCH] Fix pthread_getattr_np call in boehm-gc
- References: <20070622101932.GF7012@devserv.devel.redhat.com> <18043.41964.947319.844969@zebedee.pink>
I think the GC7 CVS code already does more or less the right thing here.
Hence I did not propagate this patch, even though it looks good to me.
Hans
> -----Original Message-----
> From: Andrew Haley [mailto:aph-gcc@littlepinkcloud.COM]
> Sent: Friday, June 22, 2007 3:27 AM
> To: Jakub Jelinek
> Cc: gcc-patches@gcc.gnu.org; java-patches@gcc.gnu.org; Boehm, Hans
> Subject: Re: [PATCH] Fix pthread_getattr_np call in boehm-gc
>
> Jakub Jelinek writes:
>
> > pthread_getattr_np can fail for various reasons and if it
> does, > pthread_attr_t is uninitialized and therefore
> neither pthread_attr_getstack > nor pthread_attr_destroy
> should be called on it.
> > E.g. if pthread_getattr_np is called from the initial
> thread on Linux > and /proc is not mapped,
> pthread_getattr_np will fail as /proc/self/maps > couldn't
> be read, pthread_attr_getstack will then return random values
> > and pthread_attr_destroy likely crash as it tries to free
> cpuset that wasn't > malloced.
> >
> > Ok for 4.3/4.2/4.1?
> >
> > 2007-06-22 Jakub Jelinek <jakub@redhat.com> >
> > * pthread_support.c (GC_get_thread_stack_base): Handle
> > pthread_getattr_np failures.
> >
>
> OK.
>
> Andrew.
>