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