Version:           kdebindings-3.4.2-0.fc4.1 (using KDE KDE 3.4.2)
Installed from:    RedHat RPMs
Compiler:          gcc 4.0.1 (Red Hat 4.0.1-5) 
OS:                Linux

SUMMARY

This deals with the qtruby bindings.
Repeatedly loading an image, scaling it and disposing of it causes a SEGV.  Attempting
to assign the image to a pixmap causes an incorrect exception to be raised.


BACKGROUND
I'm trying to load an image once, scale it and put it in a pixmap, perhaps
multiple times.  Then repeat as necessary.  When the images get to be large,
the amount of memory required starts to take far too much space, so I looked
into using dispose in order to reclaim memory earlier.  Calling GC.start
instead of dispose appears works around the memory consumption issue without
causing the problem (at the expense of a full garbage collection of course).


ENVIRONMENT
I have tested this using the RedHat kdebindings RPM for a stock fedora core 3 install:

    kdebindings-3.4.2-0.fc3.1
    qt-3.3.4-0.fc3.0

and also a slightly less stock fedora core 4:

    kdebindings-3.4.2-0.fc4.1
    qt-3.3.4-17.4.fc4.kde

as well as locally compiled on the fedora core 4 box

    korundum-3.4.92
    qtruby-1.0.10


TESTCASES
    #!/usr/bin/ruby

    require 'Qt'

    photo_name="test.jpg"
    img = nil
    scale=4
    do_detach=(ARGV.shift.nil?)

    app = Qt::Application.new(ARGV)

    1000.times do |count|
        puts count
        img = Qt::Image.new(photo_name)
        img2 = img.scale((img.width.to_f/scale).to_i, (img.height.to_f/scale).to_i)
        if !img.nil? && !img.isDisposed
                img.detach if do_detach
                img.dispose
        end
        if !img2.nil? && !img2.isDisposed
                img2.detach if do_detach
                img2.dispose
        end
    end
    __END__

Running this testcase causes the following (abbreviated) output:

    eon:~/work/zophrb% ./disposetest.rb
    0
    1
    3
    ...
    200
    201
    ./disposetest.rb:20: [BUG] Segmentation fault

Here's a stack backtrace:

    #0  0x05160ee5 in st_lookup () from /usr/lib/libruby.so.1.8
    #1  0x050e6413 in rb_undef_alloc_func () from /usr/lib/libruby.so.1.8
    #2  0x050e646f in rb_undef_alloc_func () from /usr/lib/libruby.so.1.8
    #3  0x050f3f96 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
    #4  0x050ecca5 in rb_Array () from /usr/lib/libruby.so.1.8
    #5  0x050ec333 in rb_Array () from /usr/lib/libruby.so.1.8
    #6  0x050ec2ad in rb_Array () from /usr/lib/libruby.so.1.8
    #7  0x050eaf18 in rb_Array () from /usr/lib/libruby.so.1.8
    #8  0x050f0cd0 in rb_need_block () from /usr/lib/libruby.so.1.8
    #9  0x050f10a6 in rb_yield () from /usr/lib/libruby.so.1.8
    #10 0x05121849 in rb_fix2str () from /usr/lib/libruby.so.1.8
    #11 0x050f3588 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
    #12 0x050f2b93 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
    #13 0x050f4127 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8

And some info on the image, which I can provide if needed.  However if the image
doesn't exist the program will still fault after printing lots of errors about
initializing img2.

    eon:~/work/zophrb% jhead test.jpg
    File name    : test.jpg
    File size    : 51017 bytes
    File date    : 2005:10:08 15:11:22
    Resolution   : 480 x 360

    eon:~/work/zophrb% ls -lL test.jpg
    -rw-r--r--  1 channui channui 51017 Oct  8 15:11 test.jpg


If you don't call detach on the image before disposing of it the 
Segmentation fault comes much more quickly, from somewhere completely
different:

    eon:~/work/zophrb% ./disposetest.rb without_detach
    0
    1
    2
    ./disposetest.rb:15: [BUG] Segmentation fault
    ruby 1.8.3 (2005-09-21) [i386-linux]

    #0  0x00f511e2 in xcall_QImage () from /usr/lib/libsmokeqt.so.1
    #1  0x00c91ff7 in isDerivedFromByName () from /usr/lib/site_ruby/1.8/i386-linux/qtruby.so
    #2  0x050f3572 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
    #3  0x050f2b93 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
    #4  0x050f4127 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
    #5  0x050f44eb in rb_funcall2 () from /usr/lib/libruby.so.1.8
    #6  0x050f2710 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
    #7  0x050f3f4c in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
    #8  0x050ecca5 in rb_Array () from /usr/lib/libruby.so.1.8
    #9  0x050eca41 in rb_Array () from /usr/lib/libruby.so.1.8
    #10 0x050eca41 in rb_Array () from /usr/lib/libruby.so.1.8
    #11 0x050eca41 in rb_Array () from /usr/lib/libruby.so.1.8
    #12 0x050ecb38 in rb_Array () from /usr/lib/libruby.so.1.8
    #13 0x050eddd0 in rb_Array () from /usr/lib/libruby.so.1.8
    #14 0x050f0cd0 in rb_need_block () from /usr/lib/libruby.so.1.8
    #15 0x050f10a6 in rb_yield () from /usr/lib/libruby.so.1.8
    #16 0x05121849 in rb_fix2str () from /usr/lib/libruby.so.1.8
    #17 0x050f3588 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
    #18 0x050f2b93 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
    #19 0x050f4127 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
    #20 0x050ecca5 in rb_Array () from /usr/lib/libruby.so.1.8
    #21 0x050eb9c3 in rb_Array () from /usr/lib/libruby.so.1.8
    #22 0x050e7a9d in ruby_init () from /usr/lib/libruby.so.1.8
    #23 0x050e80eb in ruby_cleanup () from /usr/lib/libruby.so.1.8
    #24 0x050e8150 in ruby_exec () from /usr/lib/libruby.so.1.8
    #25 0x050e8185 in ruby_run () from /usr/lib/libruby.so.1.8
    #26 0x08048634 in main ()

Changing the dispose order to dispose img2 first causes this error instead:

    eon:~/work/zophrb% ./disposetest.rb
    0
    1
    ...
    201
    202
    /usr/lib/site_ruby/1.8/Qt/qtruby.rb:605:in `initialize': wrong argument type #<Class:0xb7e81274> (expected Data) (TypeError)
            from /usr/lib/site_ruby/1.8/Qt/qtruby.rb:605:in `try_initialize'
            from /usr/lib/site_ruby/1.8/Qt/qtruby.rb:604:in `try_initialize'
            from ./disposetest.rb:14
            from ./disposetest.rb:12

Although slight changes in the script such as adding a begin/rescue/end block
around the offending statement cause it to SEGV again.  In a slightly more
complicated example that actually creates a pixmap:

    #!/usr/bin/ruby

    require 'Qt'

    photo_name="test.jpg"
    scale = 4
    img = nil
    pix = nil

    app = Qt::Application.new(ARGV)
    app.connect(app, SIGNAL('lastWindowClosed()'), app, SLOT('quit()'))


    1000.times do |count|
        puts count
        oldimg = img
        img = Qt::Image.new(photo_name)
        img2 = img.scale((img.width.to_f/scale).to_i, (img.height.to_f/scale).to_i)
        oldpix = pix
        begin
            pix  = Qt::Pixmap.new(img2)
        rescue
            puts img2.inspect
            raise
        end
        if !oldimg.nil? && !oldimg.isDisposed
            oldimg.detach
            oldimg.dispose
        end
        if !img2.nil? && !img2.isDisposed
            img2.detach
            img2.dispose
        end
        if !oldpix.nil? && !oldpix.isDisposed
            oldpix.detach
            oldpix.dispose
        end
    end
    __END__


we get a similar error:

    eon:~/work/zophrb% ./disposetest2.rb
    0
    1
    2
    ...
    39
    40
    #<Qt::Image:0xb7e9fde4>
    /usr/lib/site_ruby/1.8/Qt/qtruby.rb:605:in `initialize': Cannot handle 'const QImage&' as argument to QPixmap::QPixmap (ArgumentError)
            from /usr/lib/site_ruby/1.8/Qt/qtruby.rb:605:in `try_initialize'
            from /usr/lib/site_ruby/1.8/Qt/qtruby.rb:604:in `try_initialize'
            from ./disposetest2.rb:21
            from ./disposetest2.rb:14

The number of iterations completed before an error does seem to be influenced
by whether the X display is local or remote.