From: Mathieu Bouchard <matju@...>
Date: 2006-10-10T05:03:06+09:00
Subject: Re: Patch to Ruby in 2003

--8323328-274378919-1160423868=:13122
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-274378919-1160423868=:13122"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-274378919-1160423868=:13122
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sun, 23 Jul 2006, Yukihiro Matsumoto wrote:
> In message "Re: Patch to Ruby in 2003"
>    on Sun, 23 Jul 2006 01:11:00 +0900, Mathieu Bouchard <matju@artengine.=
ca> writes:
> |All versions of Ruby, up to some early 1.9, may perform an incomplete
> |mark, due to assuming that the system call-stack is empty at the moment
> |ruby_init is called. Then the sweep deletes objects still in use, which =
by
> |chain reaction corrupts memory, leads to segfaults, bus errors, unknown
> |node types, failed assertions, and various other forms of suicide.
>
> Can you point out function names that your mentioning patch is applied?=
=20
> My memory is very weak, and I couldn't find big difference in stack=20
> start detection between 1.8 and 1.9, except for ia64 support. I guess I=
=20
> am missing something.

I didn't reply because I postponed this to a time when I could sit and=20
actually figure this out because, you see, I don't have any more of an=20
answer than you have. I couldn't find it in the ChangeLog, maybe I'm=20
reading it too fast ("too diagonally"), and I don't remember how the fix=20
was made because after a bit of reading it I figured out that it seemed=20
too involved for me (though I was comfortable with probing the stack=20
myself until I trap my own segfault - that was easy).

Yesterday I have tried an idea that I got a few weeks ago, which is to do:

static t_clock *hack;
extern "C" void Init_stack(void*);
static void ruby_stack_end_hack () {
   int bogus;
   Init_stack(&bogus);
   clock_free(hack);
}

extern "C" void gridflow_setup () {
   [...]
   hack =3D clock_new((void*)0,(t_method)ruby_stack_end_hack);
   clock_delay(hack,0);
}

where clock_new, clock_delay, clock_free, are functions of the built-in=20
scheduler of the PureData programming language. This causes Init_stack to=
=20
be called from a moment when the stack is closer to empty, and pretty much=
=20
as empty as it can get during all runtime. However this causes Ruby to be=
=20
somewhat vulnerable during startup.

The big upside to this, is that it's now much easier to install GridFlow,=
=20
because Ruby 1.8 is a lot more readily available than Ruby 1.9, especially=
=20
to newbies. So basically I'm back to what it was before glibc began doing=
=20
weird things to my stack end detector(s).

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - t=E9l:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montr=E9al QC Canada
--8323328-274378919-1160423868=:13122--
--8323328-274378919-1160423868=:13122--