From: Mathieu Bouchard Date: 2006-07-23T01:11:00+09:00 Subject: Re: Patch to Ruby in 2003 --8323328-109368847-1153584605=:30944 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-109368847-1153584605=:30944" 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-109368847-1153584605=:30944 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 Sat, 22 Jul 2006 12:22:05 +0900, Mathieu Bouchard writes: > |Is it possible to get Ruby 1.8 to set the GC's stack end like Ruby 1.9 h= as > |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 withou= t > |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=20 mark, due to assuming that the system call-stack is empty at the moment=20 ruby_init is called. Then the sweep deletes objects still in use, which by= =20 chain reaction corrupts memory, leads to segfaults, bus errors, unknown=20 node types, failed assertions, and various other forms of suicide. IIRC, the solution implemented in ruby 1.9 involves a fair amount of=20 ifdefs and platform-specific code because there's no standard way to get=20 stack-end information via system headers or system functions. Over the=20 years, my program has included various ways to detect the stack-end and=20 tell Ruby about it, but recent versions of ruby do it much better (all my= =20 tricks have failed mysteriously. i suspect changes in glibc and gcc to be= =20 related, but that's beyond my level.) The problem started showing up when I embedded Ruby in realtime=20 audio/video-processing tools in 2002. This is because ruby_init gets=20 loaded as an extension to PureData when there are a dozen frames on the=20 stack. As an extension to jMax, the crashes were 100 times rarer because=20 there were less frames on the stack at the moment of ruby_init. When I=20 understood the bug in july 2003 it allowed us to consider migrating from=20 jMax to PureData (which we had by 2004 because jMax was discontinued). _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t=E9l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr=E9al QC Canada --8323328-109368847-1153584605=:30944-- --8323328-109368847-1153584605=:30944--