[Kde-bindings] [Bug 116150] New: Segmentation fault or Argument Error using images and dispose
Christopher Chan-Nui
channui+kde at tiny.org
Fri Nov 11 20:57:46 UTC 2005
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.kde.org/show_bug.cgi?id=116150
Summary: Segmentation fault or Argument Error using images and
dispose
Product: bindings
Version: unspecified
Platform: RedHat RPMs
OS/Version: Linux
Status: UNCONFIRMED
Severity: crash
Priority: NOR
Component: general
AssignedTo: kde-bindings kde org
ReportedBy: channui+kde tiny org
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.
More information about the Kde-bindings
mailing list