[#8136] Confused exception handling in Continuation Context — "Robert Dober" <robert.dober@...>

Hi all

13 messages 2006/07/06

[#8248] One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...>

I just posted this to ruby-talk. But I would also like to discuss this

33 messages 2006/07/18
[#8264] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

From my experience using both tool chains on Windows (for the ruby-prof

[#8266] Re: One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...> 2006/07/19

Tim, I'm going to top reply since your post was so long. I'm interested in

[#8267] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

> Tim, I'm going to top reply since your post was so long. I'm interested in

[#8271] my sandboxing extension!! — why the lucky stiff <ruby-core@...>

I have (what feels like) very exciting news. I finally sat down to code up my

17 messages 2006/07/19

[#8430] Re: doc patch: weakref. — "Berger, Daniel" <Daniel.Berger@...>

> -----Original Message-----

19 messages 2006/07/28
[#8434] Re: doc patch: weakref. — Yukihiro Matsumoto <matz@...> 2006/07/29

Hi,

[#8436] Re: doc patch: weakref. — Daniel Berger <djberg96@...> 2006/07/29

Yukihiro Matsumoto wrote:

[#8437] Re: doc patch: weakref. — Mauricio Fernandez <mfp@...> 2006/07/29

On Sat, Jul 29, 2006 at 07:37:24PM +0900, Daniel Berger wrote:

[#8441] Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...>

I have the following code:

18 messages 2006/07/30
[#8442] Re: Inconsistency in scoping during module_eval? — nobu@... 2006/07/30

Hi,

[#8443] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/30

Why does this:

[#8445] Re: Inconsistency in scoping during module_eval? — Yukihiro Matsumoto <matz@...> 2006/07/30

Hi,

[#8454] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/31

So to clarify...

Re: Patch to Ruby in 2003

From: Mathieu Bouchard <matju@...>
Date: 2006-07-22 16:11:00 UTC
List: ruby-core #8358
On Sun, 23 Jul 2006, Yukihiro Matsumoto wrote:

> In message "Re: Patch to Ruby in 2003"
>    on Sat, 22 Jul 2006 12:22:05 +0900, Mathieu Bouchard <matju@artengine.ca> writes:
> |Is it possible to get Ruby 1.8 to set the GC's stack end like Ruby 1.9 has
> |done for the last two years? This is for fixing a bug that I reported
> |three years ago (though I experienced it regularly four years ago without
> |knowing what it was).
> Can you elaborate?  I am not sure what exactly you mean by "set the
> GC's stack end".  If it's a small side-effect free patch, I'd love to
> back-port.

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.

IIRC, the solution implemented in ruby 1.9 involves a fair amount of 
ifdefs and platform-specific code because there's no standard way to get 
stack-end information via system headers or system functions. Over the 
years, my program has included various ways to detect the stack-end and 
tell Ruby about it, but recent versions of ruby do it much better (all my 
tricks have failed mysteriously. i suspect changes in glibc and gcc to be 
related, but that's beyond my level.)

The problem started showing up when I embedded Ruby in realtime 
audio/video-processing tools in 2002. This is because ruby_init gets 
loaded as an extension to PureData when there are a dozen frames on the 
stack. As an extension to jMax, the crashes were 100 times rarer because 
there were less frames on the stack at the moment of ruby_init. When I 
understood the bug in july 2003 it allowed us to consider migrating from 
jMax to PureData (which we had by 2004 because jMax was discontinued).

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - t駘:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montr饌l QC Canada

In This Thread