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 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


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