Salut Julien,
On Dec 19, 2009, at 12:17 AM, Julien Jassaud wrote:
Bonjour Laurent :)
Awesome! I would love to ship these as part of the MacRuby samples
once they are completed :)
Soon, hopefully !
Could you enter "thread apply all bt" into the debugger shell and
paste us the result?
Here it is. I don't understand much. The only information I can add
is that thread 4 do not systematically appear. Besides that, the
backtraces are consistent.
[...]
I looked at your project and I was able to reproduce the crashes,
which smelled like memory smashers. Then, looking at the code, I saw
bad usage of the Pointer class.
An example:
@light_position = Pointer.new_with_type('f')
@light_position[0] = -2.0
@light_position[1] = 2.0
@light_position[2] = 1.0
@light_position[3] = 0.0
This is not good, because this creates a pointer to a float of 1
element (exactly like malloc(sizeof(float)) in C) but then you set
objects to indexes (1, 2, 3) out of the pointer's bounds.
The correct code should be:
@light_position = Pointer.new_with_type('f', 4)
@light_position[0] = -2.0
@light_position[1] = 2.0
@light_position[2] = 1.0
@light_position[3] = 0.0
The second argument allows you to specify the number of elements the
Pointer will hold (by default, it's 1).
As in C, it's very easy to corrupt memory or crash the program.
Sometimes we get pointers from C or Objective-C, we wrap them inside
Pointer objects and we do not know the number of elements, but in this
case, when the Pointer is constructed by Ruby itself, I believe
MacRuby should not let you do this and appropriately raise an
exception. I will fix that ASAP.
The random crashes may perhaps disappear after you fix the code.
If the crash is random there is a possibility that it might be
related to garbage collection. A good way to know for sure is to
disable it, by setting the GC_DISABLE environment variable to any
value before starting the application.
Indeed, after :
macbook-de-julien-jassaud-2:Debug sojastar$ export GC_DISABLE=1
the application doesn't seem to crash anymore. But what should I do
now ?
I'm not familiar with OpenGL but it might be a BridgeSupport
problem... What other functions using the CGLRendererInfoObj are
failing?
Sorry, when I said all other functions, I really meant all other
calls to CGLDescribeRenderer. After a series of call to
CGLDescribeRenderer, the CGLRendererInfoObj is destroyed by
CGLDestroyRendererInfo.
If I bypass this whole section of code, I get more problems with
blablablaObj and sameblablablaObject pointer confusion. The
documentation for those types mentions only CGLRendererInfoObj,
CGLPixelFormatObj or CGLContextObj, though
It might be good to reduce this problem to a small script (even if
it can be hard, because of OpenGL).
I created a small project illustrating the problem. You can find it
here : http://github.com/sojastar/Some-MacRuby-sample-code/tree/master/buggy/
The problem starts at line 85 of file MyOpenGLView.rb.
I also had a problem with function NSBitmapImageRep. Again, a
pointer problem. Having an NSBitmapImageRep, the function bitmapData
returns an (unsigned char *) but in MacRuby, it returns an empty
string. The workaround was to create the class in an Objective C
bundle.
Thanks, I reproduce the problem here too. Could you file a ticket on
Trac, this way we won't forget to fix it?
Bonnes fêtes!
Laurent
_______________________________________________
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
