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.

Thread 4 (process 37173):

#0 0x00007fff826119da in __workq_kernreturn ()

#1 0x00007fff82611dec in _pthread_wqthread ()

#2 0x00007fff82611a55 in start_wqthread ()

Thread 3 (process 37173):

#0 0x00007fff826119da in __workq_kernreturn ()

#1 0x00007fff82611dec in _pthread_wqthread ()

#2 0x00007fff82611a55 in start_wqthread ()

Thread 2 (process 37173):

#0 0x00007fff82610bba in kevent ()

#1 0x00007fff82612a85 in _dispatch_mgr_invoke ()

#2 0x00007fff8261275c in _dispatch_queue_invoke ()

#3 0x00007fff82612286 in _dispatch_worker_thread2 ()

#4 0x00007fff82611bb8 in _pthread_wqthread ()

#5 0x00007fff82611a55 in start_wqthread ()

Thread 1 (process 37173):

#0 0x00007fff87e7011c in objc_msgSend ()

#1 0x00007fff802332b0 in -[NSCarbonMenuImpl _carbonMenuInsertItem:atCarbonIndex:] ()

#2 0x00007fff80393f5b in -[NSCarbonMenuImpl _privatePopulateCarbonMenu] ()

#3 0x00007fff80393d77 in -[NSCarbonMenuImpl _carbonPopulateEvent:handlerCallRef:] ()

#4 0x00007fff80393b60 in NSSLMMenuEventHandler ()

#5 0x00007fff86032bd7 in DispatchEventToHandlers ()

#6 0x00007fff86032126 in SendEventToEventTargetInternal ()

#7 0x00007fff86031f97 in SendEventToEventTargetWithOptions ()

#8 0x00007fff86073e2d in SendMenuPopulate ()

#9 0x00007fff86073c6e in PopulateMenu ()

#10 0x00007fff860732fe in Check1MenuForKeyEvent ()

#11 0x00007fff86072a08 in CheckMenusForKeyEvent ()

#12 0x00007fff86072644 in _IsMenuKeyEvent ()

#13 0x00007fff8607236a in IsMenuKeyEvent ()

#14 0x00007fff80393914 in -[NSCarbonMenuImpl _menuItemWithKeyEquivalentMatchingEventRef:] ()

#15 0x00007fff803936cb in _NSFindMenuItemMatchingCommandKeyEvent ()

#16 0x00007fff80264c35 in _NSHandleCarbonMenuEvent ()

#17 0x00007fff802386a2 in _DPSNextEvent ()

#18 0x00007fff80237b41 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()

#19 0x00007fff801fd747 in -[NSApplication run] ()

#20 0x00007fff801f6468 in NSApplicationMain ()

#21 0x0000000101d09770 in ?? ()

#22 0x0000000101d00314 in ?? ()

#23 0x0000000100040ff9 in ruby_run_node ()

#24 0x0000000100179769 in macruby_main ()

#25 0x0000000100000e70 in main ()

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.

Many thanks for your very prompt answer.

Julien