[#7043] RUBYOPT versioning? — Caleb Tennis <caleb@...>
Matz, others:
[#7050] RDoc patches for BigDecimal in Ruby CVS — mathew <meta@...>
Now that 1.8.4 is out and the initial flurry of problem reports has died
[#7055] More on VC++ 2005 — Austin Ziegler <halostatue@...>
Okay. I've got Ruby compiling. I'm attempting to get everything in
Hi,
On 05/01/06, nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:
On 06/01/06, Austin Ziegler <halostatue@gmail.com> wrote:
Hi,
On 09/01/06, nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:
[#7057] 64-bit Solaris READ_DATA_PENDING Revisited — Steven Lumos <steven@...>
[#7078] CRC - a proof-of-concept Ruby compiler — Anders Hkersten <chucky@...>
Hello everyone,
[#7084] mathn: ugly warnings — hadmut@... (Hadmut Danisch)
Hi,
Hadmut Danisch wrote:
Daniel Berger wrote:
*Dean Wampler *<deanwampler gmail.com> writes:
On Fri, 13 Jan 2006, mathew wrote:
On Fri, 13 Jan 2006, Mathieu Bouchard wrote:
ara.t.howard@noaa.gov wrote:
On Fri, 13 Jan 2006, James Britt wrote:
Dean Wampler <deanwampler gmail.com> writes:
On Sat, 14 Jan 2006, mathew wrote:
[#7100] core dump with ruby 1.9.0 (2006-01-10) and bdb-0.5.8 — Tanaka Akira <akr@...17n.org>
I found following test script dumps core.
>>>>> "T" == Tanaka Akira <akr@m17n.org> writes:
In article <200601110905.k0B950Op001713@moulon.inra.fr>,
[#7109] Calling flock with block? — Bertram Scharpf <lists@...>
Hi,
On Thu, 12 Jan 2006, Bertram Scharpf wrote:
[#7129] YAML.load({[]=>""}.to_yaml) — Tanaka Akira <akr@...17n.org>
I found that current YAML doesn't round trip {[]=>""}.
Hi.
Hi.
In article <20060115202203.D3624CA0.ocean@m2.ccsnet.ne.jp>,
[#7162] FileUtils.mv does not unlink source file when moving over filesystem boundary — Pav Lucistnik <pav@...>
Hi,
On Mon, 16 Jan 2006, Pav Lucistnik wrote:
[#7178] Add XHTML 1.0 Output Support to Ruby CGI — Paul Duncan <pabs@...>
The attached patch against Ruby 1.8.4 adds XHTML 1.0 output support to
[#7186] Ruby 1.9 and FHS — "Kirill A. Shutemov" <k.shutemov@...>
Build and install system changes:
[#7195] trouble due ruby redefining posix function eaccess — noreply@...
Bugs item #3317, was opened at 2006-01-24 15:33
[#7197] SSL-enabled DRb fds on SSLError? — ctm@... (Clifford T. Matthews)
Howdy,
On Jan 24, 2006, at 12:46 PM, Clifford T. Matthews wrote:
Patch worked fine against HEAD.
[#7203] bcc32's memory manager bug — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
Hi.
[#7211] Some troubles with an embedded ruby interpreter — Matt Mower <matt.mower@...>
Hi folks,
[#7216] String#scan loops forefever if scanned string is modified inside block. — noreply@...
Bugs item #3329, was opened at 2006-01-26 10:55
[#7226] Fwd: Re: Question about massive API changes — "Sean E. Russell" <ser@...>
Hello,
Sean E. Russell wrote:
>
On 1/28/06, Caleb Tennis <caleb@aei-tech.com> wrote:
On Saturday 28 January 2006 17:13, Wilson Bilkovich wrote:
Sean E. Russell wrote:
[#7249] PATCH: append option to sysread — Yohanes Santoso <ysantoso-rubycore@...>
[#7259] TCP/UDP server weird lags on 1.8.4 linux — "Bill Kelly" <billk@...>
Hi !
Re: bug - Ruby 1.8.4 Stack problem
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?