From: Guillaume C. <gco...@gm...> - 2006-07-15 13:22:33
|
Hi, When using rg2 0.15.0 on a mandriva/cooker system, if I open booh[1], load a small album and then exit booh, I see the following backtrace on the console (repeatable): *** glibc detected *** /usr/bin/ruby: free(): invalid pointer: 0x080ff70f *** ======= Backtrace: ========= /lib/i686/libc.so.6[0xb7d92173] /lib/i686/libc.so.6(__libc_free+0x83)[0xb7d95893] /usr/lib/libruby.so.1.8[0xb7ee4fcb] /usr/lib/libruby.so.1.8(rb_gc_call_finalizer_at_exit+0xa7)[0xb7f04257] /usr/lib/libruby.so.1.8[0xb7ee9e95] /usr/lib/libruby.so.1.8(ruby_cleanup+0x10f)[0xb7ef1d5f] /usr/lib/libruby.so.1.8(ruby_stop+0x1d)[0xb7ef1e6d] /usr/lib/libruby.so.1.8[0xb7efd231] /usr/bin/ruby[0x8048632] /lib/i686/libc.so.6(__libc_start_main+0xd8)[0xb7d42728] /usr/bin/ruby[0x8048561] When doing some more work instead of exiting, the problem sometimes crash booh in the middle of processing something with: *** glibc detected *** /usr/bin/ruby: corrupted double-linked list: 0x08ea1ab8 *** ======= Backtrace: ========= /lib/i686/libc.so.6[0xb7cec535] /lib/i686/libc.so.6[0xb7cee5db] /lib/i686/libc.so.6[0xb7cef8a5] /lib/i686/libc.so.6(__libc_realloc+0x105)[0xb7cf1ac5] /usr/lib/libruby.so.1.8(ruby_xrealloc+0x66)[0xb7e62266] /usr/lib/libruby.so.1.8(rb_ary_store+0xa3)[0xb7e2f013] /usr/lib/libruby.so.1.8(rb_ary_push+0x30)[0xb7e2f0d0] /usr/lib/libruby.so.1.8[0xb7e42e83] /usr/lib/libruby.so.1.8[0xb7e4ae3e] /usr/lib/libruby.so.1.8[0xb7e4b2d8] /usr/lib/libruby.so.1.8[0xb7e51356] /usr/lib/libruby.so.1.8[0xb7e5614d] /usr/lib/libruby.so.1.8(rb_yield+0x1f)[0xb7e573ef] /usr/lib/libruby.so.1.8(rb_ary_each+0x2f)[0xb7e2ff0f] /usr/lib/libruby.so.1.8[0xb7e42e8e] /usr/lib/libruby.so.1.8[0xb7e4ae3e] /usr/lib/libruby.so.1.8[0xb7e4b2d8] (...more) When downgrading to rg2 0.14.1, the problem disappers. I think that kou and possibly others have worked on suppressing memory leaks, it might be related.. Anyway, does anyone guess where is the problem? If not, can I do anything to help track the problem? [1] http://booh.org/ -- Guillaume Cottenceau - http://zarb.org/~gc/ |
From: Masao M. <mu...@hi...> - 2006-07-17 11:00:23
|
Hi, Hmm. Since Ruby-GNOME2-0.15.0, the memory management function are changed. Because there were memory leaks in Ruby-GNOME2-0.14.1. But on the other hands, it seems to free wrong object ... Anyway, Could you specify this problem? On Sat, 15 Jul 2006 15:22:24 +0200 "Guillaume Cottenceau" <gco...@gm...> wrote: > Hi, > > When using rg2 0.15.0 on a mandriva/cooker system, if I open booh[1], > load a small album and then exit booh, I see the following backtrace > on the console (repeatable): > > *** glibc detected *** /usr/bin/ruby: free(): invalid pointer: 0x080ff70f *** > ======= Backtrace: ========= > /lib/i686/libc.so.6[0xb7d92173] > /lib/i686/libc.so.6(__libc_free+0x83)[0xb7d95893] > /usr/lib/libruby.so.1.8[0xb7ee4fcb] > /usr/lib/libruby.so.1.8(rb_gc_call_finalizer_at_exit+0xa7)[0xb7f04257] > /usr/lib/libruby.so.1.8[0xb7ee9e95] > /usr/lib/libruby.so.1.8(ruby_cleanup+0x10f)[0xb7ef1d5f] > /usr/lib/libruby.so.1.8(ruby_stop+0x1d)[0xb7ef1e6d] > /usr/lib/libruby.so.1.8[0xb7efd231] > /usr/bin/ruby[0x8048632] > /lib/i686/libc.so.6(__libc_start_main+0xd8)[0xb7d42728] > /usr/bin/ruby[0x8048561] > > When doing some more work instead of exiting, the problem sometimes > crash booh in the middle of processing something with: > > *** glibc detected *** /usr/bin/ruby: corrupted double-linked list: > 0x08ea1ab8 *** > ======= Backtrace: ========= > /lib/i686/libc.so.6[0xb7cec535] > /lib/i686/libc.so.6[0xb7cee5db] > /lib/i686/libc.so.6[0xb7cef8a5] > /lib/i686/libc.so.6(__libc_realloc+0x105)[0xb7cf1ac5] > /usr/lib/libruby.so.1.8(ruby_xrealloc+0x66)[0xb7e62266] > /usr/lib/libruby.so.1.8(rb_ary_store+0xa3)[0xb7e2f013] > /usr/lib/libruby.so.1.8(rb_ary_push+0x30)[0xb7e2f0d0] > /usr/lib/libruby.so.1.8[0xb7e42e83] > /usr/lib/libruby.so.1.8[0xb7e4ae3e] > /usr/lib/libruby.so.1.8[0xb7e4b2d8] > /usr/lib/libruby.so.1.8[0xb7e51356] > /usr/lib/libruby.so.1.8[0xb7e5614d] > /usr/lib/libruby.so.1.8(rb_yield+0x1f)[0xb7e573ef] > /usr/lib/libruby.so.1.8(rb_ary_each+0x2f)[0xb7e2ff0f] > /usr/lib/libruby.so.1.8[0xb7e42e8e] > /usr/lib/libruby.so.1.8[0xb7e4ae3e] > /usr/lib/libruby.so.1.8[0xb7e4b2d8] > (...more) > > When downgrading to rg2 0.14.1, the problem disappers. I think that > kou and possibly others have worked on suppressing memory leaks, it > might be related.. Anyway, does anyone guess where is the problem? If > not, can I do anything to help track the problem? > > [1] http://booh.org/ > > -- > Guillaume Cottenceau - http://zarb.org/~gc/ > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > ruby-gnome2-devel-en mailing list > rub...@li... > https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-en > -- -- .:% Masao Mutoh<mu...@hi...> |
From: Guillaume C. <gco...@gm...> - 2006-07-17 11:16:54
|
On 7/17/06, Masao Mutoh <mu...@hi...> wrote: > Hi, > > Hmm. > Since Ruby-GNOME2-0.15.0, the memory management function are changed. > Because there were memory leaks in Ruby-GNOME2-0.14.1. > > But on the other hands, it seems to free wrong object ... > > Anyway, > Could you specify this problem? Do you mean I have to have a small program to reproduce the problem? Can't I trace it from the program itself? Because it will probably take me much time starting from my full program.. -- Guillaume Cottenceau - http://zarb.org/~gc/ |
From: Masao M. <mu...@hi...> - 2006-07-17 11:34:57
|
Hi, On Mon, 17 Jul 2006 13:16:50 +0200 "Guillaume Cottenceau" <gco...@gm...> wrote: > On 7/17/06, Masao Mutoh <mu...@hi...> wrote: > > Hi, > > > > Hmm. > > Since Ruby-GNOME2-0.15.0, the memory management function are changed. > > Because there were memory leaks in Ruby-GNOME2-0.14.1. > > > > But on the other hands, it seems to free wrong object ... > > > > Anyway, > > Could you specify this problem? > > Do you mean I have to have a small program to reproduce the problem? > Can't I trace it from the program itself? Because it will probably > take me much time starting from my full program.. Yes, if you can. But if you can't, you don't need that. Of course, I can't force it to you. Maintaining Ruby-GNOME2 is not our business. -- .:% Masao Mutoh<mu...@hi...> |
From: Kouhei S. <ko...@co...> - 2006-07-19 13:34:11
|
Hi, In <dc3...@ma...> "[ruby-gnome2-devel-en] rg2 0.15.0 and memory corruption" on Sat, 15 Jul 2006 15:22:24 +0200, "Guillaume Cottenceau" <gco...@gm...> wrote: > When using rg2 0.15.0 on a mandriva/cooker system, if I open booh[1], > load a small album and then exit booh, I see the following backtrace > on the console (repeatable): I didn't reproduce the problem on my environment (Debian/sid). Do you have any other script? -- I have some suggestions for booh. :) (1) booh should make an empty file as ext/MANIFEST to 'ruby setup.rb setup' compiles ext/rbbooh.c. (2) ext/ should be renamed to ext/booh/booh/ to 'ruby setup.rb install' installs gtkadds.so as /.../site_ruby/1.8/i486-linux/booh/gtkadds.so. (3) It may be user friendly that making thumbnail directory automatically if the directory is not exist. But this may have a bit performance issue. --- booh-0.8.6.orig/lib/booh/booh-lib.rb 2006-05-01 05:30:52.000000000 +0900 +++ booh-0.8.6/lib/booh/booh-lib.rb 2006-07-19 22:22:44.000000000 +0900 @@ -19,6 +19,7 @@ require 'iconv' require 'timeout' +require 'fileutils' require 'rexml/document' @@ -328,6 +329,7 @@ if !File.exists?(dest['filename']) cmd = nil cmd ||= "#{$convert} #{convert_options}-size #{dest['size']} -resize '#{dest['size']}>' '#{orig}' '#{dest['filename']}'" + FileUtils.mkdir_p(File.dirname(dest['filename'])) if allow_background psys(cmd) else -- Thanks, -- kou |
From: Kouhei S. <ko...@co...> - 2006-07-22 08:54:51
|
Hi, In <200...@co...> "Re: [ruby-gnome2-devel-en] rg2 0.15.0 and memory corruption" on Wed, 19 Jul 2006 22:34:01 +0900 (JST), Kouhei Sutou <ko...@co...> wrote: > > When using rg2 0.15.0 on a mandriva/cooker system, if I open booh[1], > > load a small album and then exit booh, I see the following backtrace > > on the console (repeatable): > > I didn't reproduce the problem on my environment I can reproduce the problem (perhaps) with the following script: require "glib2" require "gdk_pixbuf2" 1000.times do |i| p i loader = Gdk::PixbufLoader.new id = loader.signal_connect("size_prepared") do |l, width, height| end loader.last_write(File.read(ARGV.first)) loader.signal_handler_disconnect(id) GC.start end Thanks, -- kou |
From: Geoff Y. <g...@in...> - 2006-08-04 10:30:37
|
Kouhei Sutou wrote: > Hi, > > In <200...@co...> > "Re: [ruby-gnome2-devel-en] rg2 0.15.0 and memory corruption" on Wed, 19 Jul 2006 22:34:01 +0900 (JST), > Kouhei Sutou <ko...@co...> wrote: > >>> When using rg2 0.15.0 on a mandriva/cooker system, if I open booh[1], >>> load a small album and then exit booh, I see the following backtrace >>> on the console (repeatable): >> I didn't reproduce the problem on my environment > > I can reproduce the problem (perhaps) with the following > script: [snipped] This script does reliably fail here. Running it twice through gdb, once with GTK+ 2.8.18 & once with GTK+ 2.8.20, it produced (identical apart from the actual memory addresses) the same backtrace (both after iteration 344): ---8<--- 344 *** glibc detected *** corrupted double-linked list: 0x080bc6c0 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1211499872 (LWP 3668)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7cc89a1 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7cca2b9 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7cfc87a in __libc_message () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7d02824 in malloc_consolidate () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7d03653 in _int_malloc () from /lib/tls/i686/cmov/libc.so.6 #6 0xb7d05186 in calloc () from /lib/tls/i686/cmov/libc.so.6 #7 0xb7bb6fca in IA__g_malloc0 (n_bytes=1064) at gmem.c:150 #8 0xb72d18de in gdk_pixbuf_loader_init (loader=0x6) at gdk-pixbuf-loader.c:212 #9 0xb7c38382 in IA__g_type_create_instance (type=135116808) at gtype.c:1567 #10 0xb7c1eaa2 in g_object_constructor (type=0, n_construct_properties=0, construct_params=0x0) at gobject.c:1015 #11 0xb7c1f115 in IA__g_object_newv (object_type=135116808, n_parameters=0, parameters=0x0) at gobject.c:912 #12 0xb7c1fca5 in IA__g_object_new_valist (object_type=135116808, first_property_name=0x0, var_args=<value optimized out>) at gobject.c:955 #13 0xb7c1fe4e in IA__g_object_new (object_type=135116808, first_property_name=0x0) at gobject.c:793 #14 0xb72d210b in IA__gdk_pixbuf_loader_new () at gdk-pixbuf-loader.c:535 #15 0xb7f0fad7 in initialize_loader (argc=0, argv=0x0, self=0) at rbgdk-pixbuf-loader.c:33 #16 0xb7e555d3 in rb_iterator_p () from /usr/lib/libruby1.8.so.1.8 #17 0xb7e60089 in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8 #18 0xb7e60aef in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8 #19 0xb7e613ea in rb_obj_call_init () from /usr/lib/libruby1.8.so.1.8 #20 0xb7e8bc04 in rb_class_new_instance () from /usr/lib/libruby1.8.so.1.8 #21 0xb7e555d3 in rb_iterator_p () from /usr/lib/libruby1.8.so.1.8 #22 0xb7e60089 in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8 #23 0xb7e60aef in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8 #24 0xb7e5d75b in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8 #25 0xb7e5e9ca in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8 #26 0xb7e630b0 in rb_need_block () from /usr/lib/libruby1.8.so.1.8 #27 0xb7e643ae in rb_yield () from /usr/lib/libruby1.8.so.1.8 #28 0xb7e85d09 in rb_fix2str () from /usr/lib/libruby1.8.so.1.8 #29 0xb7e555bb in rb_iterator_p () from /usr/lib/libruby1.8.so.1.8 #30 0xb7e60089 in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8 #31 0xb7e60aef in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8 #32 0xb7e5d75b in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8 #33 0xb7e5fa47 in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8 #34 0xb7e6a6ca in rb_eval_string () from /usr/lib/libruby1.8.so.1.8 #35 0xb7e6a71a in ruby_exec () from /usr/lib/libruby1.8.so.1.8 #36 0xb7e6c82e in ruby_run () from /usr/lib/libruby1.8.so.1.8 #37 0x080485dc in main () ---8<--- The precise error does depend on the image - when I was using other images, it failed at different points. For example, running the same script with the same image, but not using gdb, it fails after the 11th iteration, and the error message is: ---8<--- 11 *** glibc detected *** malloc(): memory corruption: 0x0808408e *** Aborted ---8<--- With a smaller png, again without gdb, I get: ---8<--- 95 crash.rb:11: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Aborted ---8<--- Just for the record, I'm using GLib 2.10.3, GTK+ 2.8.20 (now), Ruby 1.8.4 & Ruby-GNOME2 cvs. Apart from Ruby-GNOME2 cvs, they are all standard Ubuntu dapper packages. HTH, Geoff. |
From: <eu...@tr...> - 2006-08-05 03:08:24
|
> Kouhei Sutou wrote: >> Hi, >> >> In <200...@co...> >> "Re: [ruby-gnome2-devel-en] rg2 0.15.0 and memory corruption" on Wed, >> 19 Jul 2006 22:34:01 +0900 (JST), >> Kouhei Sutou <ko...@co...> wrote: >> >>>> When using rg2 0.15.0 on a mandriva/cooker system, if I open booh[1], >>>> load a small album and then exit booh, I see the following backtrace >>>> on the console (repeatable): >>> I didn't reproduce the problem on my environment >> >> I can reproduce the problem (perhaps) with the following >> script: > [snipped] [snipped] Fromt he looks of the backtrace, it does look like it's going through the general construction of the GTK -> GLIB Object, for the Pixbuff Class. From what I can tell though, that here seems to be a memory leak between these two points. This becomes more apparent, when you factor in the next two examples. > ---8<--- > 11 > *** glibc detected *** malloc(): memory corruption: 0x0808408e *** > Aborted > ---8<--- > > With a smaller png, again without gdb, I get: > ---8<--- > 95 > crash.rb:11: [BUG] Segmentation fault > ruby 1.8.4 (2005-12-24) [i486-linux] > > Aborted > ---8<--- [snipped] If I understand the results of the testing methods you used, that with a larger PNG Image, you load up atleast 11 images, before the program will crash. Where as with a smaller PNG Image, it'll load up atleast 95 of thoes images, before it will crash. This can mean one of two things. There is a problem with GLib, in how it's handling the memory. And infact, there may be a need to create a delay between loads, instead of trying to load them up one right after the other. The second problem, would mean, that GLIB is fine, in the core source. Remember that each distro does make modifications to the source code to make a library compile within their enviroment. Prime examples being the way Red Hat/Fedora Core compiles the program, and Debian (Basic Debian), compiles the program. As I noticed, your using the packages that come directly from Ubuntu. Have you had a chance to try this within another enviroment, in which you have plain vanillia source code for the GTK/Gnome Library? More often then not, since this isn't an apparent problem amongst all platforms, that there has to be some patches generated for the GTK Package that is distributed by Ubuntu, that may be causing some memory leaks, in which case, this may need to be brought up with the Ubuntu Support List. The main thing to remember, is that Ruby/Gnome2 Bindings, do not actually load the data for Gtk images, and such. Infact, to keep the weight down on the Extensions, they are mainly the C Counterpart, in which to get the actual utilizations of the basic functions within the GTK API, from Ruby. Then again, this is just my 2 cents. Mario Steele |
From: Guillaume C. <gco...@gm...> - 2006-07-30 17:50:48
|
> > When using rg2 0.15.0 on a mandriva/cooker system, if I open booh[1], > > load a small album and then exit booh, I see the following backtrace > > on the console (repeatable): > > I didn't reproduce the problem on my environment > (Debian/sid). Do you have any other script? I'm sorry, I can't reproduce the problem anymore! :/ -- Guillaume Cottenceau - http://zarb.org/~gc/ |
From: Guillaume C. <gco...@gm...> - 2006-07-31 19:47:19
|
On 7/30/06, Guillaume Cottenceau <gco...@gm...> wrote: > > > When using rg2 0.15.0 on a mandriva/cooker system, if I open booh[1], > > > load a small album and then exit booh, I see the following backtrace > > > on the console (repeatable): > > > > I didn't reproduce the problem on my environment > > (Debian/sid). Do you have any other script? > > I'm sorry, I can't reproduce the problem anymore! :/ Seems that there are still problems, but not the same. Maybe related to the fact that I've upgraded to gtk 2.10.1. I can see: /usr/bin/booh:392: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i586-linux-gnu] Aborted Notice: I cannot reproduce a problem with your short gdk pixbuf loading script. I will send a backtrace if I can get one. This problem is so much annoying: all people using booh must revert to rg2 0.14.1 now! :( -- Guillaume Cottenceau - http://zarb.org/~gc/ |
From: Guillaume C. <gco...@gm...> - 2006-08-01 18:16:29
|
> I will send a backtrace if I can get one. This problem is so much Here it is. Does it help? *** glibc detected *** /usr/bin/ruby: corrupted double-linked list: 0x0acaa318 *** ======= Backtrace: ========= /lib/i686/libc.so.6[0xb7ce4236] /lib/i686/libc.so.6[0xb7ce63cb] /lib/i686/libc.so.6(malloc+0x85)[0xb7ce7d85] /lib/i686/libc.so.6[0xb7c97a39] /lib/i686/libc.so.6(iconv_open+0x1aa)[0xb7c9747a] /usr/lib/ruby/1.8/i586-linux-gnu/iconv.so[0xb7f027c0] /usr/lib/ruby/1.8/i586-linux-gnu/iconv.so[0xb7f02a18] /usr/lib/libruby.so.1.8[0xb7e3cea3] /usr/lib/libruby.so.1.8[0xb7e44e3e] /usr/lib/libruby.so.1.8[0xb7e452d8] /usr/lib/libruby.so.1.8[0xb7e4b356] /usr/lib/libruby.so.1.8[0xb7e4b26f] /usr/lib/libruby.so.1.8[0xb7e4d5ae] /usr/lib/libruby.so.1.8[0xb7e44e54] /usr/lib/libruby.so.1.8[0xb7e452d8] /usr/lib/libruby.so.1.8[0xb7e4b477] /usr/lib/libruby.so.1.8[0xb7e4b2e2] /usr/lib/libruby.so.1.8[0xb7e4b95e] /usr/lib/libruby.so.1.8[0xb7e4b2e2] /usr/lib/libruby.so.1.8[0xb7e4ca2c] /usr/lib/libruby.so.1.8[0xb7e4ca2c] /usr/lib/libruby.so.1.8[0xb7e44e54] /usr/lib/libruby.so.1.8[0xb7e452d8] /usr/lib/libruby.so.1.8[0xb7e4b477] /usr/lib/libruby.so.1.8[0xb7e4ca2c] /usr/lib/libruby.so.1.8[0xb7e4ca2c] /usr/lib/libruby.so.1.8[0xb7e5014d] /usr/lib/libruby.so.1.8[0xb7e50b58] /usr/lib/libruby.so.1.8[0xb7e3ca97] /usr/lib/libruby.so.1.8[0xb7e44e3e] /usr/lib/libruby.so.1.8[0xb7e452d8] /usr/lib/libruby.so.1.8(rb_apply+0x74)[0xb7e4aef4] /usr/lib/ruby/site_ruby/1.8/i586-linux-gnu/glib2.so[0xb7b4cf93] /usr/lib/libruby.so.1.8(rb_protect+0x11a)[0xb7e3e87a] /usr/lib/ruby/site_ruby/1.8/i586-linux-gnu/glib2.so(rbgutil_protect+0x33)[0xb7b445e3] /usr/lib/ruby/site_ruby/1.8/i586-linux-gnu/glib2.so[0xb7b4d660] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x11b)[0xb7af72bb] -- Guillaume Cottenceau - http://zarb.org/~gc/ |