[Gc] OS X patch against 6.8: segfault fix (and other OS X fixes)
hans.boehm at hp.com
Wed Dec 13 16:02:04 PST 2006
I finally got around to putting this in my source trees. Thanks again,
and sorry for the delay.
In the GC7 tree, I also attempted to clean up the patch, and integrate
various other outstanding and
sometimes conflicting MACOS X patches. I will do a smoke check on an
old 10.2 PPC machine at home.
Assuming that passes, I will check it in.
I put Allan's patch basically unchanged into the potential 6.9 tree,
since it's an outright bug fix for existing platforms. I'm not
currently inclined to put the rest of the changes there.
In reading the code, I was unconvinced that the X86_64 bit code
currently makes sense. (Presumably those extra 8 registers need to be
traced?) Nor do I know to what extent Apple supports that, and it's
supposed to make sense.
> -----Original Message-----
> From: Allan Hsu [mailto:allan at counterpop.net]
> Sent: Tuesday, October 31, 2006 2:24 PM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] OS X patch against 6.8: segfault fix
> On Oct 26, 2006, at 5:52 PM, Boehm, Hans wrote:
> > Thanks. And sorry for the delay.
> > Clearly the new code is better than the old.
> > I assume that task_threads() implicitly allocates vm of exactly the
> > required size? This seems a bit brittle in that if you get
> the size
> > wrong, it will fail very rarely. Hence I wanted to double-check ...
> The darwin/mach documentation I've seen on this is unclear.
> vm_allocate() only returns memory in page-sized chunks, and
> vm_deallocate frees the region that "...starts at the
> beginning of the virtual page containing address and ends at
> the end of the virtual page containing address + size - 1."
> My assumption is that task_threads allocates however many
> pages are needed to contain the resulting array and
> vm_deallocate will free the right number of pages when called.
> > The code would look slightly clearer to me if the
> deallocation code at
> > the end also used prev_list and prevcount, making it clear
> that it's
> > just doing the same cleanup as in the loop.
> I have no problem with this. I waffled between what you
> described and what I submitted in the patch.
More information about the Gc