[#5737] returning strings from methods/instance_methods — TRANS <transfire@...>

I was just wondering why with #methods and #instance_methods, it was

11 messages 2005/09/08

[#5796] proposed attr writer patch — Daniel Berger <Daniel.Berger@...>

Hi all,

18 messages 2005/09/16

[#5798] Makefile error in OpenSLL extension (on Windows) — noreply@...

Bugs item #2472, was opened at 2005-09-16 18:56

11 messages 2005/09/17
[#5800] Re: [ ruby-Bugs-2472 ] Makefile error in OpenSLL extension (on Windows) — nobu.nokada@... 2005/09/17

Hi,

[#5851] Re: RubyGems in Ruby HEAD — Paul van Tilburg <paul@...>

Hi all,

34 messages 2005/09/21
[#5867] Re: RubyGems in Ruby HEAD — mathew <meta@...> 2005/09/21

Paul van Tilburg wrote:

[#5870] Re: RubyGems in Ruby HEAD — Marc Dequènes (Duck) <Duck@...> 2005/09/21

[#5920] Re: RubyGems in Ruby HEAD — mathew <meta@...> 2005/09/22

Marc Dequ竪nes (Duck) wrote:

[#5926] Re: RubyGems in Ruby HEAD — Pascal Terjan <pterjan@...> 2005/09/23

On 9/22/05, mathew <meta@pobox.com> wrote:

[#5931] Re: RubyGems in Ruby HEAD — Austin Ziegler <halostatue@...> 2005/09/23

On 9/23/05, Pascal Terjan <pterjan@gmail.com> wrote:

[#5898] Delegate and Forwardable Documentation — James Edward Gray II <james@...>

I've tried to send these files through a couple of times now with

17 messages 2005/09/22
[#5911] Re: Delegate and Forwardable Documentation — James Edward Gray II <james@...> 2005/09/22

On Sep 22, 2005, at 9:02 AM, James Edward Gray II wrote:

[#5924] Re: Delegate and Forwardable Documentation — James Edward Gray II <james@...> 2005/09/23

On Sep 22, 2005, at 11:53 AM, James Edward Gray II wrote:

[#5941] Re: Delegate and Forwardable Documentation — Yukihiro Matsumoto <matz@...> 2005/09/23

Hi,

[#5942] Re: Delegate and Forwardable Documentation — James Edward Gray II <james@...> 2005/09/23

On Sep 23, 2005, at 10:54 AM, Yukihiro Matsumoto wrote:

[#5947] Re: Delegate and Forwardable Documentation — Yukihiro Matsumoto <matz@...> 2005/09/23

Hi,

[#5921] Mutually dependent libs double loading. — TRANS <transfire@...>

I'm on Ruby 1.8.2.

14 messages 2005/09/23
[#5923] Re: Mutually dependent libs double loading. — Florian Gro<florgro@...> 2005/09/23

TRANS wrote:

[#5985] Finally an answer to my RubyGems question and some small suggestions — TRANS <transfire@...>

I appreciate those that attempted to offer me some info on this issue.

9 messages 2005/09/26

[#6001] Require Namepaces and RubyGems' effect on LoadPath problem — TRANS <transfire@...>

I've added namespaces to require. Works like this:

94 messages 2005/09/26
[#6002] Re: Require Namepaces and RubyGems' effect on LoadPath problem — Austin Ziegler <halostatue@...> 2005/09/26

On 9/26/05, TRANS <transfire@gmail.com> wrote:

[#6003] Re: Require Namepaces and RubyGems' effect on LoadPath problem — TRANS <transfire@...> 2005/09/26

On 9/26/05, Austin Ziegler <halostatue@gmail.com> wrote:

[#6005] Re: Require Namepaces and RubyGems' effect on LoadPath problem — Austin Ziegler <halostatue@...> 2005/09/26

On 9/26/05, TRANS <transfire@gmail.com> wrote:

[#6007] gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Sam Roberts <sroberts@...> 2005/09/26

Quoting halostatue@gmail.com, on Tue, Sep 27, 2005 at 06:02:07AM +0900:

[#6013] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Austin Ziegler <halostatue@...> 2005/09/27

On 9/26/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6014] Re: gems is a language change, not a pkging system — Sam Roberts <sroberts@...> 2005/09/27

Quoting halostatue@gmail.com, on Tue, Sep 27, 2005 at 10:29:17AM +0900:

[#6015] Re: gems is a language change, not a pkging system — James Edward Gray II <james@...> 2005/09/27

On Sep 26, 2005, at 8:54 PM, Sam Roberts wrote:

[#6016] Re: gems is a language change, not a pkging system — Sam Roberts <sroberts@...> 2005/09/27

Quoting james@grayproductions.net, on Tue, Sep 27, 2005 at 11:06:01AM +0900:

[#6018] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/26/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6019] Re: gems is a language change, not a pkging system — Sam Roberts <sroberts@...> 2005/09/27

Quoting halostatue@gmail.com, on Tue, Sep 27, 2005 at 11:49:14AM +0900:

[#6024] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/27/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6025] Re: gems is a language change, not a pkging system — Ralph Amissah <ralph.amissah@...> 2005/09/27

> Right now, they're watching people who have pretty much sat on the side

[#6026] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/27/05, Ralph Amissah <ralph.amissah@gmail.com> wrote:

[#6043] Re: gems is a language change, not a pkging system — Ralph Amissah <ralph.amissah@...> 2005/09/28

I'll greatly weaken my post, and give everyone the opportunity to head me

[#6044] Re: gems is a language change, not a pkging system — Hugh Sasse <hgs@...> 2005/09/28

On Wed, 28 Sep 2005, Ralph Amissah wrote:

[#6073] Re: gems is a language change, not a pkging system — Mauricio Fern疣dez <mfp@...> 2005/09/28

Hello,

[#6074] Re: gems is a language change, not a pkging system — Jim Weirich <jim@...> 2005/09/29

On Wednesday 28 September 2005 07:35 pm, Mauricio Fern疣dez wrote:

[#6017] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/26/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6046] Re: gems is a language change, not a pkging system — "Sean E. Russell" <ser@...> 2005/09/28

On Monday 26 September 2005 22:41, Austin Ziegler wrote:

[#6050] Re: gems is a language change, not a pkging system — Hugh Sasse <hgs@...> 2005/09/28

On Wed, 28 Sep 2005, Sean E. Russell wrote:

[#6207] Re: gems is a language change, not a pkging system — "Sean E. Russell" <ser@...> 2005/10/10

On Wednesday 28 September 2005 08:54, Hugh Sasse wrote:

[#6045] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — "Sean E. Russell" <ser@...> 2005/09/28

On Monday 26 September 2005 21:29, Austin Ziegler wrote:

[#6048] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Austin Ziegler <halostatue@...> 2005/09/28

On 9/28/05, Sean E. Russell <ser@germane-software.com> wrote:

[#6059] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Dominique Brezinski <dominique.brezinski@...> 2005/09/28

On 9/28/05, Austin Ziegler <halostatue@gmail.com> wrote:

[#6061] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Austin Ziegler <halostatue@...> 2005/09/28

On 9/28/05, Dominique Brezinski <dominique.brezinski@gmail.com> wrote:

[#6062] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Dominique Brezinski <dominique.brezinski@...> 2005/09/28

For what it is worth, I live life behind an authenticated proxy, so I

[#6099] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — "Sean E. Russell" <ser@...> 2005/09/30

On Wednesday 28 September 2005 08:43, Austin Ziegler wrote:

[#6009] Re: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — Ralph Amissah <ralph.amissah@...>

(i) correction, segfault is with official ruby 1.8.3 (2005-09-21), not

21 messages 2005/09/27
[#6010] Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — Ralph Amissah <ralph.amissah@...> 2005/09/27

[sorry for duplicate post]

[#6079] Re: Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — ts <decoux@...> 2005/09/29

>>>>> "R" == Ralph Amissah <ralph.amissah@gmail.com> writes:

[#6081] Re: Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — ts <decoux@...> 2005/09/29

>>>>> "t" == ts <decoux@moulon.inra.fr> writes:

[#6082] Re: Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — Tanaka Akira <akr@...17n.org> 2005/09/29

In article <200509291419.j8TEJYid015419@moulon.inra.fr>,

Re: ruby 1.8.3 (2005-06-23) [i486-linux] sisu segfault

From: why the lucky stiff <ruby-core@...>
Date: 2005-09-26 20:45:26 UTC
List: ruby-core #6000
Ralph Amissah wrote:

>The bug is low level be with ruby, and require 'yaml'
>line number 56 in sysenv.rb
>causes segfault even if nothing is done,
>(guess i need to triple check this,
>and there certainly may be some old formatting in yaml used,
>but by my current reckoning i am not loading the files
>[before the segfault])
>  
>
I can replicate this with ruby-1.8.3, but not with ruby_1_8 trunk.  My 
segfault is happening during loading of help.rb, however.  Backtrace 
follows.

_why


--
why@stungun ~/sand/ruby-1.8.3 $ gdb ruby
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db 
library "/lib/libthread_db.so.1".

(gdb) run /usr/bin/sisu -?
Starting program: /home/why/sand/ruby-1.8.3/ruby /usr/bin/sisu -?

Program received signal SIGSEGV, Segmentation fault.
rb_newobj () at gc.c:384
384         freelist = freelist->as.free.next;
(gdb) bt
#0  rb_newobj () at gc.c:384
#1  0x08094281 in rb_node_newnode (type=NODE_IVAR, a0=0, a1=0, a2=0) at 
parse.y:4450
#2  0x08094b35 in gettable (id=10354) at parse.y:4810
#3  0x0809000d in ruby_yyparse () at parse.y:2175
#4  0x08090c87 in yycompile (f=0x81de9a8 
"/usr/lib/ruby/site_ruby/1.8/sisu/0.26/help.rb", line=0)
    at parse.y:2570
#5  0x080ac4d4 in load_file (fname=0x81de9a8 
"/usr/lib/ruby/site_ruby/1.8/sisu/0.26/help.rb", script=0)
    at ruby.c:943
#6  0x080ac777 in rb_load_file (fname=0x2 <Address 0x2 out of bounds>) 
at ruby.c:960
#7  0x0805e857 in rb_load (fname=3084213296, wrap=0) at eval.c:6679
#8  0x0805f304 in rb_require_safe (fname=3084213496, safe=0) at eval.c:7006
#9  0x080687a2 in call_cfunc (func=0x805ed90 <rb_f_require>, 
recv=3083049904, len=0, argc=0,
    argv=0xbf854618) at eval.c:5530
#10 0x0805c4ba in rb_call0 (klass=3084684436, recv=3083049904, id=9545, 
oid=2, argc=1, argv=0xbf854618,
    body=0xb7db97a8, flags=2) at eval.c:5672
#11 0x0805cda5 in rb_call (klass=3084684436, recv=3083049904, mid=9545, 
argc=1, argv=0xbf854618, scope=1)
    at eval.c:5900
#12 0x08057e1f in rb_eval (self=3083049904, n=0x2) at ruby.h:638
#13 0x080599ab in module_setup (module=3083049904, n=0xb7c39bec) at 
eval.c:4075
#14 0x08058dd2 in rb_eval (self=3084679536, n=0x2) at eval.c:4005
#15 0x0805e8bc in rb_load (fname=3082470304, wrap=0) at eval.c:6685
#16 0x0805f304 in rb_require_safe (fname=3082470404, safe=0) at eval.c:7006
#17 0x080687a2 in call_cfunc (func=0x805ed90 <rb_f_require>, 
recv=3084502536, len=0, argc=0,
    argv=0xbf855938) at eval.c:5530
#18 0x0805c4ba in rb_call0 (klass=3084684436, recv=3084502536, id=9545, 
oid=2, argc=1, argv=0xbf855938,
    body=0xb7db97a8, flags=2) at eval.c:5672
#19 0x0805cda5 in rb_call (klass=3084684436, recv=3084502536, mid=9545, 
argc=1, argv=0xbf855938, scope=1)
    at eval.c:5900
#20 0x08057e1f in rb_eval (self=3084502536, n=0x2) at ruby.h:638
#21 0x080574ca in rb_eval (self=3084502536, n=0x2) at eval.c:3187
#22 0x08057612 in rb_eval (self=3084502536, n=0x2) at eval.c:3236
#23 0x080599ab in module_setup (module=3084502536, n=0xb7d9c6a8) at 
eval.c:4075
#24 0x08058dd2 in rb_eval (self=3084679536, n=0x2) at eval.c:4005
#25 0x0805423d in ruby_exec_internal () at eval.c:1543
#26 0x08054276 in ruby_exec () at eval.c:1563
#27 0x080542a0 in ruby_run () at eval.c:1573
#28 0x080523e5 in main (argc=2, argv=0x2, envp=0xbf857614) at main.c:46

In This Thread

Prev Next