[#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: core dump with ruby 1.9.0 (2006-01-10) and bdb-0.5.8

From: Tanaka Akira <akr@...17n.org>
Date: 2006-01-11 21:58:13 UTC
List: ruby-core #7108
In article <200601110953.k0B9rRN2005865@moulon.inra.fr>,
  ts <decoux@moulon.inra.fr> writes:

>>>>>> "T" == Tanaka Akira <akr@m17n.org> writes:
>
> T> GC.stress = true
>
>  This is this that it don't like. I'll see what I can do.

"GC.stress = true" makes GC related problem more
reproducible.

However it is possible to reproduce the problem without
"GC.stress = true" if I modified bdb-0.5.8/src/env.c as
follows.

I think it is also possible to reproduce the problem without
the modification if some number of objects are allocated
before exit to cause GC in rb_protect.  I.e. I think the
problem exists anyway (in ruby interpreter or bdb binding,
or both)

% diff -u env.c- env.c
--- env.c-      2006-01-12 06:48:43.200735680 +0900
+++ env.c       2006-01-12 06:49:42.202766008 +0900
@@ -799,6 +799,7 @@
         envst->db_ary.mark = Qtrue;
         for (i = 0; i < envst->db_ary.len; i++) {
             if (rb_respond_to(ary[i], rb_intern("close"))) {
+                rb_gc();
                 rb_protect(bdb_protect_close, ary[i], 0);
             }
         }
zsh: exit 1     diff -u env.c- env.c
% cat tst1.rb     
require 'bdb'
require 'fileutils'

DBDIR = "db"

FileUtils.rm_rf(DBDIR)
Dir.mkdir(DBDIR)

@db_env = BDB::Env.new(DBDIR, BDB::CREATE | BDB::INIT_MPOOL)
options = {}
options["env"] = @db_env
options["set_store_key"] = lambda {|k| k }
GC.start
db = BDB::Btree.open('d', nil, BDB::CREATE, 0644, options)
db["k"] = "v"

exit
% ruby -I. tst1.rb
zsh: segmentation fault (core dumped)  ruby -I. tst1.rb
% gdb ruby core
GNU gdb 6.3-debian
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 "x86_64-linux"...Using host libthread_db library "/lib/libthread_db.so.1".

Core was generated by `ruby -I. tst1.rb'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /home/akr/ruby/bdb/bdb-0.5.8/src/bdb.so...done.
Loaded symbols for /home/akr/ruby/bdb/bdb-0.5.8/src/bdb.so
Reading symbols from /usr/lib/libdb-4.2.so...done.
Loaded symbols for /usr/lib/libdb-4.2.so
Reading symbols from /home/akr/ruby/lib/ruby/1.9/x86_64-linux/etc.so...done.
Loaded symbols for /home/akr/ruby/lib/ruby/1.9/x86_64-linux/etc.so
#0  0x000000000049701c in st_lookup (table=0x2, key=2929, value=0x7fbfffeee0) at st.c:240
240         hash_val = do_hash(key, table);
(gdb) bt
#0  0x000000000049701c in st_lookup (table=0x2, key=2929, value=0x7fbfffeee0) at st.c:240
#1  0x00000000004a9804 in classname (klass=182905301976) at variable.c:144
#2  0x00000000004a9923 in rb_class_path (klass=182905301976) at variable.c:181
#3  0x00000000004a9bfc in rb_class_name (klass=182905301976) at variable.c:270
#4  0x00000000004a9c13 in rb_class2name (klass=182905301976) at variable.c:276
#5  0x00000000004a9c36 in rb_obj_classname (obj=182905302696) at variable.c:282
#6  0x00000000004bf071 in rb_check_type (x=182905302696, t=18) at error.c:227
#7  0x0000002a95c71926 in bdb_i_close (dbst=0x6a4bc0, flags=0) at common.c:731
#8  0x0000002a95c71f72 in bdb_close (argc=0, argv=0x0, obj=182905347056) at common.c:865
#9  0x000000000042bc51 in call_cfunc (func=0x2a95c71e78 <bdb_close>, recv=182905347056, len=-1, argc=0, argv=0x0)
    at eval.c:5432
#10 0x000000000041ca5a in rb_call0 (klass=182894364344, recv=182905347056, id=7785, oid=7785, argc=0, argv=0x0, 
    body=0x2a955a8028, flags=8) at eval.c:5643
#11 0x000000000041d516 in rb_call (klass=182894364344, recv=182905347056, mid=7785, argc=0, argv=0x0, scope=CALLING_FCALL)
    at eval.c:5816
#12 0x000000000041d8ee in rb_funcall2 (recv=182905347056, mid=7785, argc=0, argv=0x0) at eval.c:5922
#13 0x0000002a95c839e7 in bdb_protect_close (obj=182905347056) at env.c:787
#14 0x000000000041bc0f in rb_protect (proc=0x2a95c839b9 <bdb_protect_close>, data=182905347056, state=0x0) at eval.c:5229
#15 0x0000002a95c83a84 in bdb_final (envst=0x6ba6f0) at env.c:803
#16 0x0000002a95c83b7a in bdb_env_free (envst=0x6ba6f0) at env.c:840
#17 0x0000000000434c6e in rb_gc_call_finalizer_at_exit () at gc.c:1875
#18 0x00000000004117b0 in ruby_finalize_1 () at eval.c:1456
#19 0x0000000000411915 in ruby_cleanup (ex=0) at eval.c:1493
#20 0x0000000000411b08 in ruby_stop (ex=6) at eval.c:1537
#21 0x0000000000411b55 in ruby_run () at eval.c:1549
#22 0x000000000040f543 in main (argc=3, argv=0x7fbffff9d8, envp=0x7fbffff9f8) at main.c:43
(gdb) 
-- 
Tanaka Akira

In This Thread

Prev Next