[#7055] More on VC++ 2005 — Austin Ziegler <halostatue@...>

Okay. I've got Ruby compiling. I'm attempting to get everything in

17 messages 2006/01/05
[#7058] Re: More on VC++ 2005 — nobuyoshi nakada <nobuyoshi.nakada@...> 2006/01/06

Hi,

[#7084] mathn: ugly warnings — hadmut@... (Hadmut Danisch)

Hi,

22 messages 2006/01/10
[#7097] Re: mathn: ugly warnings — Daniel Berger <Daniel.Berger@...> 2006/01/10

Hadmut Danisch wrote:

[#7098] Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/10

Daniel Berger wrote:

[#7118] Re: Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/12

*Dean Wampler *<deanwampler gmail.com> writes:

[#7226] Fwd: Re: Question about massive API changes — "Sean E. Russell" <ser@...>

Hello,

23 messages 2006/01/28
[#7228] Re: Question about massive API changes — Caleb Tennis <caleb@...> 2006/01/28

>

Re: bug - Ruby 1.8.4 Stack problem

From: Pav Lucistnik <pav@...>
Date: 2006-01-25 17:33:27 UTC
List: ruby-core #7209
Doug Bryant p晥e v 鑼 26. 01. 2006 v 02:28 +0900:

> I recently upgraded from 1.8.2 to 1.8.4 and am encountering core dumps
> on FreeBSD 5.4. The same code works fine on OSX with 1.8.4.
> 
> I had a lengthy discussion with chris2 from the ruby user mailing list
> this morning and it seems to be stack related.
> 
> Basically what is happening is a piece of code which builds a
> REXML::Document and then calls REXML::Xpath.match(...) on that
> document.  When the code executes the XPath.match call, a core dump is
> produced.  I also discovered that almost any method which does
> anything on the constructed REXML::Document will produce a core dump.
> Also, when I manually put the offending code into irb, it works just
> fine. On OSX with 1.8.4 and on freebsd with 1.8.2 the code works fine
> also.
> 
> Attached is the gdb backtrace.  It is 432 elements deep for the code
> that calls REXML::XPath.match(...)
> 
> chris2 also had me run the following test for recursion:
> 
> ruby -e 'def d(x); p x; d x+1; end; d 0'
> 
> I ran it on both the freebsd box and the osx box.  The results are interesting.
> 
> On the freebsd box:
> 
> default ulimit of 65536 using 1.8.4 = 151 last result and core dump
> ulimit -s 16000 using 1.8.4 = 151 last result and core dump
> 
> defualt ulimit of 65536 using 1.8.2 = 49165 last result and error
> "stack level too deep"
> ulimit -s 16000 using 1.8.2 = 11423 last result and error "stack level too deep"
> 
> 
> and on the osx box:
> 
> default ulimit of 8192 using 1.8.4 = 1109 and error "stack level too deep"
> ulimit -s 16000 using 1.8.4 = 2316 and error "stack level too deep"
> 
> Have there been any other reports of similar errors?  Is this a known
> bug?  Is there a work around?

It has been reported before. The thread stack seems to be either very
small, or very easily filled up. You can cimcurvent this by rebuilding
ruby without pthread support, if you don't need threading - see
WITHOUT_PTHREAD port option.

As for core dumping instead of catching "stack level too deep" error,
I don't know workaround for that.

Could very well be that FreeBSD libpthread is to blame here, it's
relatively new code.

-- 
Pav Lucistnik <pav@oook.cz>
              <pav@FreeBSD.org>

What is the airspeed velocity of an unladen swallow?

Attachments (1)

signature.asc (187 Bytes, application/pgp-signature)

In This Thread