Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault

[sorry for duplicate post]
(i) correction, segfault is with official ruby 1.8.3 (2005-09-21), not
before
(ii) segfault _can_ be made to occur in several sisu files, trying to repair
it with changes to ruby code,
(iii) it is fixed most simply by removing: require 'yaml'
..

(i) i got my ruby segfault versions wrong it should be the official
1.8.3release
<http://www.jus.uio.no/sisu/SiSU/download#deb_debug>ruby 1.8.3 (2005-09-21)
[i486-linux]
segfault does not happen with earlier ruby 1.8.3 (2005-06-26) [i486-linux]
as
suggested by previous post,
(... i seldom work in dual environments, and took ruby version accidentally
from
the working one, whilst dashing out.)

(ii) i have a fix for sisu, remove yaml,
why should code in written ruby (without extensions) cause a segfault in C
anyway?
Before removing: require 'yaml'
searching for what might cause it in the code written in ruby, i got the
segfault to
appear to occur in several different sisu libraries, help.rb was one of
them, sysenv.rb,
and defaults.rb were others.

(iii) all that is done now to 'FIX' the segfault, is
(a) loading of yaml files (optional configure files, and version info), is
commented out and
(b) require 'yaml' removed
having done that, it appears as though
require 'yaml'
alone, is sufficient to cause the segfault, without loading yaml files
(which is why i have not looked to see what might have changed with the yaml
format yet,
that, and being out a fair bit at the moment)
see note on uncommenting require 'yaml' in sysenv.rb (line number 56 i think
it was)

not sure what i overlook, am not used to having to faff about with
ruby-core/standard library, segfaults. Actually i chose ruby as the language
to code in,
it suits level of abstraction at which i need to work, having used perl
previously,
which is by way of confessing and rather lamely, i don't do C.

http://www.jus.uio.no/sisu/SiSU/download#development
http://www.jus.uio.no/sisu/SiSU/changelog#0.27
http://www.jus.uio.no/sisu/SiSU/download#dev_debian
http://www.jus.uio.no/sisu/SiSU/download#debug
http://www.jus.uio.no/sisu/SiSU/download#deb_debug

why_ glad you can replicate the segfault. sorry for tone, i _much_
appreciate all
work done for ruby. Am alarmed at having things go wrong that appear to
be beyond my control, and in ruby 1.8.3 official release.

(i.e. if hypothetically, i code ruby badly, i expect ruby error messages,
and have been comforable with those, not segfaults),

and, i thought these types of changes happened with major version changes,
there was no problem with:
ruby 1.8.3 (2005-06-26) [i486-linux]
and i am told no obvious changes that should affect:
ruby 1.8.3 (2005-09-21) [i486-linux]
which does segfault;
which is somehow even more alarming, as sisu-0.26.1 was unchanged between
them, what happened between ruby versions?
(when i last checked well a month or so ago, sisu worked fine with 1.9.)

i am also a bit worried that given that this does not affect other software,

it might not be prioritised/ made to go away, (quickly), (and might somehow
get forgotten or
placed on a back burner).

i could re-engineer sisu to work without yaml, but would rather not,
(and would rather not see another segfault when coding ruby,
somewhere else perhaps, who knows what i might have to consider dropping
next).

if given a specific idea as to what is likely to make yaml/ruby segfault, i
don't mind
a recode... more confusingly i am told that require 'yaml' does not cause it
directly...
(i must be overlooking some line where i do something with yaml? on
requiring it
& why segfault?)

Being faced with a segfault that moved all over the place, and locating the
problem was a bit of a nightmare, ruby has never behaved that way to me...

And incidentally, i am a BIG fan of why_ amongst others,
again apologies for my tone,
my frustration is i hope not completely un-understandable,
(even if i somehow contribute to making this segfault happen)

Good speed in setting me right. Thanks,
Ralph

PS am out/offline a fair bit at the moment.

On 9/26/05, why the lucky stiff <[e-mail]> wrote:
>
> 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
>
>


--
email: [e-mail]
.: [e-mail]
SiSU: http://www.jus.uio.no/sisu



--
email: [e-mail]
.: [e-mail]
SiSU: http://www.jus.uio.no/sisu