This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Ruby testsuite failures because of pointer mangling on 32-bit ARM?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>, David Miller <davem at davemloft dot net>
- Cc: pinskia at gmail dot com, will dot newton at linaro dot org, libc-alpha at sourceware dot org
- Date: Sat, 14 Dec 2013 10:34:37 -0500
- Subject: Re: Ruby testsuite failures because of pointer mangling on 32-bit ARM?
- Authentication-results: sourceware.org; auth=none
- References: <20131210 dot 211901 dot 1840879367475720601 dot davem at davemloft dot net> <52A94FB5 dot 7060100 at redhat dot com> <20131212 dot 121441 dot 261870704107659875 dot davem at davemloft dot net> <20131212 dot 132053 dot 446942135510037848 dot davem at davemloft dot net> <20131213025324 dot GZ24286 at brightrain dot aerifal dot cx>
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.
Cheers,
Carlos.