Segfaulting Ruby by abusing PStore


(Jeremy Henty) #1

OK, it’s a dirty trick to change class definitions behind PStore’s
back. If I run these two scripts, the second segfaults, saying:

ruby_pstore_bug.rb:9: [BUG] Segmentation fault
ruby 1.6.7 (2002-03-01) [i586-linux]
Aborted (core dumped)

···

#!/usr/bin/env ruby

require ‘pstore’

class Foo
def initialize(foo)
@foo = foo
end
end

pstore = PStore.new(’.pstore_bug.pstore’)
pstore.transaction do
pstore[‘foo’] = Foo.new(‘akdhakjsh’)
end

#!/usr/bin/env ruby

require ‘pstore’

Foo = Struct.new(:foo)

pstore = PStore.new(’.pstore_bug.pstore’)
pstore.transaction do
pstore[‘foo’].foo
end

You have to call Foo#foo to get the segfault, just extracting the
object is not enough.

I’m running Ruby 1.6.7 on GNU/Linux, kernel 2.2.20 . I saw the same
behaviour with Ruby 1.6.6 .

Here’s the gdb trace:

GNU gdb 19991004
Copyright 1998 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 “i386-redhat-linux”…
Core was generated by `ruby ruby_pstore_bug.rb’.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/local/lib/libruby.so.1.6…done.
Reading symbols from /lib/libdl.so.2…done.
Reading symbols from /lib/libcrypt.so.1…done.
Reading symbols from /lib/libm.so.6…done.
Reading symbols from /lib/libc.so.6…done.
Reading symbols from /lib/ld-linux.so.2…done.
#0 0x40135d21 in __kill () from /lib/libc.so.6
(gdb) where
#0 0x40135d21 in __kill () from /lib/libc.so.6
#1 0x40135996 in raise (sig=6) at …/sysdeps/posix/raise.c:27
#2 0x401370b8 in abort () at …/sysdeps/generic/abort.c:88
#3 0x40032314 in rb_check_type (x=1074479568, t=1073824816) at error.c:178
#4 0x40090996 in sigsegv () at signal.c:393
#5 0x40135c48 in __restore ()
at …/sysdeps/unix/sysv/linux/i386/sigaction.c:127
#6 0x4003e4ca in call_cfunc (func=0x4009a9d0 <rb_struct_ref0>,
recv=1076008856, len=0, argc=0, argv=0x0) at eval.c:4260
#7 0x4003eac2 in rb_call0 (klass=1076013696, recv=1076008856, id=9001,
argc=0, argv=0x0, body=0x4022a60c, nosuper=1) at eval.c:4394
#8 0x4003f355 in rb_call (klass=1076013696, recv=1076008856, mid=9001,
argc=0, argv=0x0, scope=0) at eval.c:4614
#9 0x40039804 in rb_eval (self=1076083936, n=0x4022e89c) at eval.c:2544
#10 0x4003ca03 in rb_yield_0 (val=1076012136, self=1076083936, klass=0,
acheck=0) at eval.c:3622
#11 0x40038b3d in rb_eval (self=1076012136, n=0x4022c2f4) at eval.c:2358
#12 0x4003a203 in rb_eval (self=1076012136, n=0x4022c2e0) at eval.c:2690
#13 0x4003ca03 in rb_yield_0 (val=2332942, self=1076012136, klass=0, acheck=0)
at eval.c:3622
#14 0x40049641 in rb_f_catch (dmy=1076012136, tag=2332942) at eval.c:9005
#15 0x4003e4dc in call_cfunc (func=0x400495a4 <rb_f_catch>, recv=1076012136,
len=1, argc=1, argv=0xbfffca60) at eval.c:4263
#16 0x4003eac2 in rb_call0 (klass=1076087956, recv=1076012136, id=3745,
argc=1, argv=0xbfffca60, body=0x4023b2e0, nosuper=1) at eval.c:4394
#17 0x4003f355 in rb_call (klass=1076087956, recv=1076012136, mid=3745,
argc=1, argv=0xbfffca60, scope=1) at eval.c:4614
#18 0x40039804 in rb_eval (self=1076012136, n=0x4022c36c) at eval.c:2544
#19 0x4003867f in rb_eval (self=1076012136, n=0x4022c2a4) at eval.c:2276
#20 0x40038beb in rb_eval (self=1076012136, n=0x4022bcf0) at eval.c:2368
#21 0x40038e73 in rb_eval (self=1076012136, n=0x4022cb00) at eval.c:2408
#22 0x40038e73 in rb_eval (self=1076012136, n=0x4022bb10) at eval.c:2408
#23 0x40037b63 in rb_eval (self=1076012136, n=0x4022bafc) at eval.c:2025
#24 0x4003eef7 in rb_call0 (klass=1076029196, recv=1076012136, id=9025,
argc=0, argv=0x0, body=0x4022bafc, nosuper=0) at eval.c:4521
#25 0x4003f355 in rb_call (klass=1076029196, recv=1076012136, mid=9025,
argc=0, argv=0x0, scope=0) at eval.c:4614
#26 0x40039804 in rb_eval (self=1076083936, n=0x4022e950) at eval.c:2544
#27 0x4003867f in rb_eval (self=1076083936, n=0x4022ea68) at eval.c:2276
#28 0x40035298 in eval_node (self=1076083936, node=0x4022ea68) at eval.c:1057
#29 0x4003573b in ruby_run () at eval.c:1189
#30 0x8048713 in main (argc=2, argv=0xbffff5b4, envp=0xbffff5c0) at main.c:50
(gdb) q

Regards,

Jeremy Henty


(Yukihiro Matsumoto) #2

Hi,

···

In message “Segfaulting Ruby by abusing PStore” on 02/06/03, Jeremy Henty jeremy@chaos.org.uk writes:

OK, it’s a dirty trick to change class definitions behind PStore’s
back. If I run these two scripts, the second segfaults, saying:

It cannot be fixed fundamentally in 1.6 but it is fixed in 1.7.
Don’t tease my poor baby too much.

						matz.

(Jeremy Henty) #3

In article 1023111679.725927.2329.nullmailer@picachu.netlab.jp,
Yukihiro Matsumoto wrote:

OK, it’s a dirty trick to change class definitions behind PStore’s
back. If I run these two scripts, the second segfaults, saying:

It cannot be fixed fundamentally in 1.6 …

I suspected that might be the case, but didn’t know enough about
Marshal/Dump internals to judge. It’s not a problem: I have no need
for Ruby to survive this sort of abuse.

Don’t tease my poor baby too much.

It was a mistake on my part: I was merrily rewriting my application
and forgot I was PStore-ing some of the classes that I had changed.
BTW I think PStore is great! Being able to add persistence to an
application with just a few extra lines of code is fantastic.

Regards,

Jeremy Henty

···

In message “Segfaulting Ruby by abusing PStore” > on 02/06/03, Jeremy Henty jeremy@chaos.org.uk writes:

http://www.rubygarden.com/ruby?JeremyHenty

Ruby: programmer’s best friend
– John Robson