This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ruby testsuite failures because of pointer mangling on 32-bit ARM?


On Sat, Dec 14, 2013 at 10:34:37AM -0500, Carlos O'Donell wrote:
> On 12/12/2013 09:53 PM, Rich Felker wrote:
> > On Thu, Dec 12, 2013 at 01:20:53PM -0500, David Miller wrote:
> >> From: David Miller <davem@davemloft.net>
> >> Date: Thu, 12 Dec 2013 12:14:41 -0500 (EST)
> >>
> >>> From: "Carlos O'Donell" <carlos@redhat.com>
> >>> Date: Thu, 12 Dec 2013 00:55:01 -0500
> >>>
> >>>> It treats the jmp_buf as an array of VALUE sized pointers that
> >>>> it can examine to determine if there are pointers to the heap.
> >>>
> >>> Sounds similar to what any other garbage collector will do, scan
> >>> the processes address space looking for pointers.
> >>>
> >>> I'm pretty sure Boehm-GC does something similar, although perhaps
> >>> it scans the entire process stack from the point in which it is
> >>> called instead of using jmpbuf's to delineate spans of stack
> >>> areas like Ruby does.
> >>
> >> And, indirectly, realize that even a straight stack scan is going
> >> to potentially break if you start mangling pointers in jmpbuf.
> >>
> >> Consider the case where if the jmpbuf is on the processes stack, and
> >> normally it would get scanned by GC and the pointer followed to find
> >> memory references, and now that would not work because the pointer is
> >> mangled.
> >>
> >> I think all of these schemes are legitimate and erroneously broken
> >> by pointer mangling.
> > 
> > Applying garbage collection to C objects is about as far away from
> > "legitimate" as you can possibly get.
> > 
> > Rich
> > 
> 
> This now bug #9249 in the ruby bug tracker.
> 
> https://bugs.ruby-lang.org/issues/9249
> 
> I hope we can discuss alternatives to the current implementation
> and come up with something we can all agree on.
> 
> The strongest argument to make is to consider that ruby *is* part
> of the "implementation" and therefore privy to the contents of
> jmp_buf. If glibc agrees to that then we would need to document
> this hard requirement and work out some way to coordinate jmp_buf
> changes with ruby.

Ruby has a choice: it's either a portable application that's a
language interpreter/runtime, or part of the implementation. You can't
be both. "Portable" and "part of the implementation" are mutually
exclusive labels.

There are plenty of legitimate portable ways to implement the
interpreter/runtime for a language with GC using C. Applying GC to C
objects is not one of them. Correct approaches involve managing the
language's objects separately from C objects and applying GC there
rather than to the whole process's address space. As an added bonus,
this gets you correct garbage collection rather than conservative
(fake) garbage collection which is subject to memory-exhaustion
vulnerabilities via data emulating pointers.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]