[MacRuby-devel] Some OpenGL sample code

[Laurent Sansonetti]

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