Ruby/Gosu

[Kevin Pratt]

Hi there,

I am currently trying to get Ruby/Gosu working on my Gentoo system. I
can get it to build fine but when ever I try to load an image I get a
segmentation fault. I figure this has something to so with the boost
C++ libraries that Gosu uses to store image data and how they are
installed on my computer - but I can't be 100% sure. I can compile
and run C++ code against the Gosu library all the Tutorials are built
when you compile the library and they all run correctly. Also to add
to the strangeness a friend of mine wrote a simple ruby application
with Ruby/Gosu and it works, but if I change the order in which the
images are loaded it segfaults as well.

On to the question.....

What would be the best way to debug this problem? I need to find out
where the segfault is happening. In ruby because of the SO, in the
Gosu SO because of invalid memory access etc.

Any thoughts would be appreciated.

Kevin Pratt

 

[Florian Groß]

I am currently trying to get Ruby/Gosu working on my Gentoo system. I
can get it to build fine but when ever I try to load an image I get a
segmentation fault. I figure this has something to so with the boost
C++ libraries that Gosu uses to store image data and how they are
installed on my computer - but I can't be 100% sure. I can compile
and run C++ code against the Gosu library all the Tutorials are built
when you compile the library and they all run correctly. Also to add
to the strangeness a friend of mine wrote a simple ruby application
with Ruby/Gosu and it works, but if I change the order in which the
images are loaded it segfaults as well.

This seems to be a known bug that only rarely occurs on some systems.
The Gosu team is working on debugging this, but unfortunately the Linux
person has been quite inactive lately. I think help on solving this
problem is highly welcome.

On to the question.....

What would be the best way to debug this problem? I need to find out
where the segfault is happening. In ruby because of the SO, in the
Gosu SO because of invalid memory access etc.

Hm, I'm not sure. Using gdb would probably be a good idea, but I can't
give any more specific advise on this -- sorry. I'll post back in case
more information arrives.

 

[Kevin Pratt]

Good to know that I'm not the only one I thought I was going crazy...=20
I've only just started working with gdb and not found much useful
information. I'll see if I can figure out more information about what
is causing the problem.

It's tricky to debug something when you don't know where to look... I
think I have narrowed it down to somewhere in the OpenGL part of the
code. But it will take some more time to figure out if I am right.


I'll post back if I find anything more specific.

Thanks for the reply.

 

[Gennady Bystritsky]

On Jul 3, 2005, at 6:10, Kevin Pratt wrote:

...

On to the question.....

What would be the best way to debug this problem? I need to find out
where the segfault is happening. In ruby because of the SO, in the
Gosu SO because of invalid memory access etc.

Any thoughts would be appreciated.

Kevin Pratt

Ruby handles all signals by itself. It is great most of the time
except when a segfault occurs and you need to figure out where. For
such cases I usually end up resetting a signal handling to the
default either by compiling a custom ruby or from a C extension that
I load first. For segmentation fault it would be:

#include <signal.h>
...
signal(SIGSEGV, SIG_DFL);

When a problem occurs, you will have a core dump, which may help you
in figuring out where it happened (providing the stack is not
corrupted beyond recognition, gdb's command "bt" shows you the stack
trace). Make sure core dumps are allowed on you system. "ulimit -c"
shows you the limit for core file size. It is 0 (cores disabled) by
default on some systems. Use "ulimit -c unlimited" to to remove the
limitation for the current session.

Hope it helps,
Gennady.

 

[Max Nickel]

What would be the best way to debug this problem? I need to find out
where the segfault is happening. In ruby because of the SO, in the
Gosu SO because of invalid memory access etc.

Any thoughts would be appreciated.

Kevin Pratt

I'd recommend gdb.
run 'gdb ruby', inside gdb type 'run <path_to_your_ruby_script>', wait
till it segfaults and type 'bt' et voila

regards
/max

 

[Kevin Pratt]

Thanks for you guys help, I'm new to gdb and did not know about the bt
command (it was exactly what I was looking for) I have been able to
figure out where the program is failing. But I have not done any
work with the boost set of libraries and that is where it seems to be
failing. I've checked the values of the parameters being passed to
the call and they seem to be in good shape.

If any one here is familiar with the Gosu library it uses boost. Line
33 contains a call to the boost BlockAllocator I have checked the
inputs and they seem valid.

Even when I try a std::cerr <<" some string"; I get a segfalut on
that line instead. But that stack strace complains about problems
with and unhandled exception in the << operator.

Any suggestions would be great... Thanks for all your help so far.=20
This is a tricky one. If the Gosu linux developer is around I'll
gladly give him a shell account on my computer to try and figure this
out.

I'll keep hacking away at it and see what I can find.

Below is the output from the bt command in gdb.

#0 0xb7dba74b in mallopt () from /lib/libc.so.6
#1 0xb7db9803 in malloc () from /lib/libc.so.6
#2 0xb791a28e in operator new () from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/libstdc++.so.5
#3 0xb7cf82fe in Gosu::OpenGL::Texture::alloc (this=3D0x80911d8,
width=3D255, height=3D255, x=3D0xbfffb43c, y=3D0xbfffb438) at Texture.cpp:3=
3
#4 0xb7cf060a in Gosu::OpenGL::GraphicsImpl::createImage
(this=3D0x808f3d0, src=3D@0xbfffb750, srcX=3D0, srcY=3D0, srcWidth=3D253,
srcHeight=3D253, borderFlags=3D12)
at OpenGL.cpp:149
#5 0xb7cfa17b in LargeImageData (this=3D0x80911a8,
imageCreator=3D@0x808f3d0, source=3D@0xbfffb750, partWidth=3D253,
partHeight=3D253, borderFlags=3D15) at LargeImageData.cpp:48
#6 0xb7cf025a in Gosu::OpenGL::GraphicsImpl::createImage
(this=3D0x808f3d0, src=3D@0xbfffb750, srcX=3D0, srcY=3D0, srcWidth=3D640,
srcHeight=3D480, borderFlags=3D15)
at OpenGL.cpp:111
#7 0xb7cef072 in Gosu::Graphics::createImage (this=3D0x808e390,
src=3D@0xbfffb750, srcX=3D0, srcY=3D0, srcWidth=3D640, srcHeight=3D480,
hardBorders=3Dtrue) at Graphics.cpp:108
#8 0xb7cf5709 in Image (this=3D0x8091198, graphics=3D@0x808e390,
source=3D@0xbfffb750, srcX=3D0, srcY=3D0, srcWidth=3D640, srcHeight=3D480,
hardBorders=3Dtrue) at Image.cpp:18
#9 0xb7cd5f89 in RubyGosu::Image_initialize (argc=3D3, argv=3D0xbfffbe38,
self=3D3084121996) at Image.cpp:102
#10 0xb7f5e8d6 in rb_throw () from /usr/lib/libruby18.so.1.8
#11 0xb7f51075 in rb_with_disable_interrupt () from /usr/lib/libruby18.so.1=
8
#12 0xb7f5196b in rb_with_disable_interrupt () from /usr/lib/libruby18.so.1=
8
#13 0xb7f51ede in rb_funcall2 () from /usr/lib/libruby18.so.1.8
#14 0xb7f54b09 in rb_obj_call_init () from /usr/lib/libruby18.so.1.8

(argc=3D3, argv=3D0xbfffbe38, cls=3D3084126776) at DataWrapper.hpp:23

#16 0xb7f5e8d6 in rb_throw () from /usr/lib/libruby18.so.1.8
#17 0xb7f51075 in rb_with_disable_interrupt () from /usr/lib/libruby18.so.1=
8
#18 0xb7f5196b in rb_with_disable_interrupt () from /usr/lib/libruby18.so.1=
8
#19 0xb7f4c3a6 in rb_Array () from /usr/lib/libruby18.so.1.8
#20 0xb7f4bd5f in rb_Array () from /usr/lib/libruby18.so.1.8
#21 0xb7f51252 in rb_with_disable_interrupt () from /usr/lib/libruby18.so.1=
8
#22 0xb7f5196b in rb_with_disable_interrupt () from /usr/lib/libruby18.so.1=
8
#23 0xb7f51ede in rb_funcall2 () from /usr/lib/libruby18.so.1.8
#24 0xb7f54b09 in rb_obj_call_init () from /usr/lib/libruby18.so.1.8
#25 0xb7cdbdf2 in
RubyGosu:efault_new<boost::shared_ptr<RubyGosu::WindowImpl> >
(argc=3D0, argv=3D0x0, cls=3D3084122696) at DataWrapper.hpp:23
#26 0xb7f5e8d6 in rb_throw () from /usr/lib/libruby18.so.1.8
#27 0xb7f51075 in rb_with_disable_interrupt () from /usr/lib/libruby18.so.1=
8
#28 0xb7f5196b in rb_with_disable_interrupt () from /usr/lib/libruby18.so.1=
8
#29 0xb7f4c3a6 in rb_Array () from /usr/lib/libruby18.so.1.8
#30 0xb7f4c293 in rb_Array () from /usr/lib/libruby18.so.1.8
#31 0xb7f484dc in ruby_cleanup () from /usr/lib/libruby18.so.1.8
#32 0xb7f48534 in ruby_exec () from /usr/lib/libruby18.so.1.8
#33 0xb7f48571 in ruby_run () from /usr/lib/libruby18.so.1.8
#34 0x08048683 in main ()

 

[jan.luecker]

I am currently trying to get Ruby/Gosu working on my Gentoo system. I

can get it to build fine but when ever I try to load an image I get a
segmentation fault.

Hi Kevin,

I'm the person who ported Gosu to Linux. This segmentation fault also
occurs on my (Gentoo) system. I was not able to find the reason for it.
With C++ Gosu runs just fine and the code for Ruby integration works on
Windows, so my last guess was that it's a Ruby problem. (If you look at
ruby.h you can hardly imagine this code to be running. ) Also I do
not use Ruby, so it wasn't my priority. But I'd be glad if you'd find
the error.
At the moment I am really busy (3 exams the next two weeks! Eeeeks!) so
I won't be able to help you.

Good luck!

Jan

 

[Julian Raschke]

Hey,

this is Gosu's Windows guy. I'm tired and not sure if I already sent this
message. Whatever.

First off, I am really ashamed of that bug. I have no time to get into
Linux, gcc, OpenGL, X and Ruby at once though, so I can't track it down in
live action. Any help is highly appreciated, as this bug is what keeps me
from posting Gosu to public Ruby sites.

Here's some facts about the crash:
- Only happens for some people
- Only happens for some combination of loading images
- Only happens in Ruby; rewriting the same app in C++ doesn't crash
- Crashes at an allocation that shouldn't have any reason to crash

So my first guess is that something corrupts the heap's structure. Are there
any heap corruption detection tools for gcc that work with Ruby running?

Other than that, I could only flood all related source files with assert()
and upload them for further testing.

Thanks so far for all your support!

Julian

 

[Pavel Vozenilek]

If any one here is familiar with the Gosu library it uses boost. Line
33 contains a call to the boost BlockAllocator I have checked the
inputs and they seem valid.

If you identify bug in Boost, please send email on
their developer list so it can get fixed.

If you suspect Boost you may try latest Boost version (1.32)
or perhaps fresh (pre-1.33 state) CVS version
(http://www.boost-consulting.com/boost.tar.bz2).

Thanks,
/Pavel