[#3479] Missing .document files for ext/ libraries — Brian Candler <B.Candler@...>
The ri documentation for zlib, strscan and iconv doesn't get built by 'make
On Wednesday, October 6, 2004, 11:18:33 PM, Brian wrote:
Just been building CVS head and was surprised at how long it now takes
On Die, 2004-10-19 at 16:47, Dave Thomas wrote:
[#3484] compilation error — Wybo Dekker <wybo@...>
In the current cvs I get, on make:
On Mon, Oct 11, 2004 at 07:21:28AM +0900, Wybo Dekker wrote:
[#3486] Location of missing end — Markus <markus@...>
Over the past week or so there has been a thread on ruby-talk ("Quality
[#3492] Re: ANN: Free-form-operators patch — Markus <markus@...>
> In message "Re: ANN: Free-form-operators patch"
Hi,
On Mon, 2004-10-11 at 16:16, Yukihiro Matsumoto wrote:
On Monday 11 October 2004 08:09 pm, Markus wrote:
Hi,
On Monday 11 October 2004 09:38 pm, Yukihiro Matsumoto wrote:
[#3517] Kernighan & Richie ---> prototypes ? — Johan Holmberg <holmberg@...>
[#3523] segfault in ruby-1.8.2p2 — Brian Candler <B.Candler@...>
I can reliably get ruby-1.8.2p2 to segfault on my system, which is:
[#3538] TCPSocket.new(host, port).readline hangs on Windows — Jos Backus <jos@...>
With recent CVS versions (both ruby_1_8 branch and HEAD), the following
Hi,
On Wed, Oct 20, 2004 at 07:43:31AM +0900, Yukihiro Matsumoto wrote:
[#3551] ubygems missing? — "trans. (T. Onoma)" <transami@...>
I've never been one for compiling code, so I bet this is a simple fix, but
[#3561] 1.8.2 - what can we do to help? — Dave Thomas <dave@...>
Folks:
Hi,
On Oct 26, 2004, at 9:55 PM, Yukihiro Matsumoto wrote:
On Wed, 2004-10-27 at 06:11, Francis Hwang wrote:
On Wed, 27 Oct 2004, Yukihiro Matsumoto wrote:
Hi,
On Wed, 27 Oct 2004, Yukihiro Matsumoto wrote:
Hi,
On Wednesday 27 October 2004 08:51 am, Yukihiro Matsumoto wrote:
[#3573] Small issues with Symbols — Florian Gro<florgro@...>
Moin!
[#3590] Re: Bug tracking project on RubyForge... — "Berger, Daniel" <Daniel.Berger@...>
> -----Original Message-----
Sure...
Hi,
[#3596] Float and Bignum — "trans. (T. Onoma)" <transami@...>
Hi all,
Hi,
On Thursday 28 October 2004 02:00 am, Yukihiro Matsumoto wrote:
[#3600] Ruby Vs. ... might find comparison of interest. — "trans. (T. Onoma)" <transami@...>
trans. (T. Onoma) wrote:
[#3610] Tadayoshi Funaba's Date2 — "trans. (T. Onoma)" <transami@...>
Tadayoshi Funaba has a lib on RAA called Date2, the additions/improvements to
Hi --
On Friday 29 October 2004 07:03 am, David A. Black wrote:
[#3611] Memory leak in ruby_1_8 — David Ross <dross@...>
Hello,
[#3617] TEST BUG — noreply@...
Bugs item #1000, was opened at 2004-10-28 09:12
[#3638] Ruby, pthreads, and HPUX 11 — Jamis Buck <jgb3@...>
I'm finally trying to delve into the issue of Ruby not compiling
>>>>> "J" == Jamis Buck <jgb3@email.byu.edu> writes:
[#3655] autoload — Joel VanderWerf <vjoel@...>
Ruby, pthreads, and HPUX 11
I'm finally trying to delve into the issue of Ruby not compiling
properly on HPUX (11, in my case) when --enable-pthreads is set. (This
is necessary in order to use, for instance, any Oracle module, since the
Oracle libs are compiled against pthreads).
This references ruby-talk:107425 and ruby-talk:115767 (see the stack
traces given in those threads).
I am compiling Ruby 1.8.2.
To review the issue: miniruby compiles fine, but when it is run, it dies
in either shellwords.rb or ftools.rb (not sure what the determining
factor is, in this case). I've managed to narrow it down and can get the
following to segfault consistently:
miniruby -e "loop { break }"
It appears to be an issue with memory being clobbered during a longjmp
call. In the case of the one-liner above, the it is the longjmp that is
invoked as a result of the 'break'.
I've managed to narrow it down to the following. In eval.c, there is a
function "rb_yield_0" (line 4619). In "rb_yield_0", there is a variable
"old_cref", which is used to save the value of the global "ruby_cref"
(line 4645). On line 4727 an EXEC_TAG() is invoked (which does a setjmp,
I believe). At this point, the value of old_cref is correct.
Later, when the 'break' statement causes a longjmp to be executed,
execution resumes at line 4727. At this point, the value of old_cref is
incorrect (0x00000000). I put various trace statements throughout the
code (esp. rb_eval) and was able to see that the value in old_cref was
correct up to the very moment that longjmp was called.
Thus, it appears that something is occuring in the longjmp call that
clobbers the stack, but only when pthreads is linked in.
I am certainly in over my head here, and I have no idea where else to
look, or what else to try. I'm hoping the above summary will ring some
bells for someone, or at least suggest another avenue that I might try.
Thanks!
Jamis
--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis