Rg2 0.15.0 and memory corruption

Desktop Ruby-Gnome 2
1

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 C. - 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

2

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 C.” [email protected] wrote:

/usr/lib/libruby.so.1.8[0xb7ee4fcb]
crash booh in the middle of processing something with:
/usr/lib/libruby.so.1.8(rb_ary_push+0x30)[0xb7e2f0d0]
(…more)

–

.:% Masao M.[email protected]

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

3

Hi,

On Mon, 17 Jul 2006 13:16:50 +0200
“Guillaume C.” [email protected] wrote:

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 M.[email protected]

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

4

Hi,

In [email protected]
“[ruby-gnome2-devel-en] rg2 0.15.0 and memory corruption” on Sat, 15
Jul 2006 15:22:24 +0200,
“Guillaume C.” [email protected] 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. :slight_smile:

(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

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share
your
opinions on IT & business topics through brief surveys – and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

5

Hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] rg2 0.15.0 and memory corruption” on Wed,
19 Jul 2006 22:34:01 +0900 (JST),
Kouhei S. [email protected] 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

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share
your
opinions on IT & business topics through brief surveys – and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

6

On 7/17/06, Masao M. [email protected] 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 C. - 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

7

On 7/30/06, Guillaume C. [email protected] 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! :confused:

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! :frowning:

–
Guillaume C. - http://zarb.org/~gc/

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share
your
opinions on IT & business topics through brief surveys – and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

8

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! :confused:

–
Guillaume C. - http://zarb.org/~gc/

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share
your
opinions on IT & business topics through brief surveys – and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

9

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 C. - http://zarb.org/~gc/

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share
your
opinions on IT & business topics through brief surveys – and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

10

Kouhei S. wrote:

Hi,

In [email protected]

“Re: [ruby-gnome2-devel-en] rg2 0.15.0 and memory corruption” on
Wed,

19 Jul 2006 22:34:01 +0900 (JST),

Kouhei S. [email protected] 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 S.

11

Kouhei S. wrote:

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=) 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.

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share
your
opinions on IT & business topics through brief surveys – and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV