Laurent Sansonetti
lsans****@apple*****
Wed Feb 28 03:24:42 JST 2007
I managed to track the problem to a specific revision change (post 1585), now fixing... Laurent On Feb 23, 2007, at 1:58 PM, Laurent Sansonetti wrote: > I can reproduce, arigato! I'm off for a few days but will try to > investigate this the week-end if I can. > > Laurent > > On Feb 23, 2007, at 8:16 AM, Fujimoto Hisa wrote: > >> Hi Laurent >> >> Two samples, CIBevelSample and CIMicroPaint, down with the current >> (1589). >> These seemed to work until a few days ago. I can't find out the cause >> yet, and appended the snippet of the stack trace. >> >> about CIMicroPaint, it down at the line 134 in sample/SampleCIView.rb >> >> @context.drawImage_atPoint_fromRect(@image, rr.origin, rr) >> >> -- >> hisa >> >> >> # snippet of >> Exception: EXC_BAD_ACCESS (0x0001) >> Codes: KERN_INVALID_ADDRESS (0x0001) at 0x72662e71 >> >> Thread 0 Crashed: >> 0 libSystem.B.dylib 0x90000f88 pthread_mutex_lock >> + 17 >> 1 com.apple.opengl 0x931c059e >> CGLGetVirtualScreen + 172 >> 2 com.apple.QuartzCore 0x93ed41bb >> fe_cgl_context_screen >> + 32 >> 3 com.apple.QuartzCore 0x93ebdac0 - >> [CIOpenGLContextImpl >> updateContext] + 61 >> 4 com.apple.QuartzCore 0x93ebd9b6 - >> [CIOpenGLContextImpl >> render:] + 196 >> 5 com.apple.QuartzCore 0x93ed6377 -[CIContext >> drawImage:inRect:fromRect:] + 1437 >> 6 com.apple.QuartzCore 0x93ed854a -[CIContext >> drawImage:atPoint:fromRect:] + 121 >> 7 com.apple.rubycocoa 0x0003229d ffi_call_SYSV + 29 >> 8 com.apple.rubycocoa 0x0003223e ffi_call + 98 >> 9 com.apple.rubycocoa 0x0002f917 rb_ffi_dispatch + >> 579 >> 10 com.apple.rubycocoa 0x000211ee objcptr_cptr + 1465 >> 11 com.apple.rubycocoa 0x000219c4 objcptr_cptr + 3471 >> 12 libruby.1.dylib 0x96092259 >> rb_with_disable_interrupt + 450 >> 13 libruby.1.dylib 0x9609a973 Init_eval + 17638 >> 14 libruby.1.dylib 0x9609b1d8 Init_eval + 19787 >> 15 libruby.1.dylib 0x960987a1 Init_eval + 8980 >> 16 libruby.1.dylib 0x96099281 Init_eval + 11764 >> 17 libruby.1.dylib 0x9609ae6b Init_eval + 18910 >> 18 libruby.1.dylib 0x9609b1d8 Init_eval + 19787 >> 19 libruby.1.dylib 0x9609e796 rb_thread_wait_fd >> + 938 >> >> >> # from CIMicroPaint.crash.log >> Exception: EXC_BAD_ACCESS (0x0001) >> Codes: KERN_INVALID_ADDRESS (0x0001) at 0x439c0010 >> >> Thread 0 Crashed: >> 0 libSystem.B.dylib 0x90000f88 pthread_mutex_lock >> + 17 >> 1 com.apple.opengl 0x931c059e >> CGLGetVirtualScreen + 172 >> 2 com.apple.QuartzCore 0x93ed41bb >> fe_cgl_context_screen >> + 32 >> 3 com.apple.QuartzCore 0x93ebdac0 - >> [CIOpenGLContextImpl >> updateContext] + 61 >> 4 com.apple.QuartzCore 0x93ebd9b6 - >> [CIOpenGLContextImpl >> render:] + 196 >> 5 com.apple.QuartzCore 0x93ed6377 -[CIContext >> drawImage:inRect:fromRect:] + 1437 >> 6 com.apple.QuartzCore 0x93ed854a -[CIContext >> drawImage:atPoint:fromRect:] + 121 >> 7 com.apple.rubycocoa 0x0003229d ffi_call_SYSV + 29 >> 8 com.apple.rubycocoa 0x0003223e ffi_call + 98 >> 9 com.apple.rubycocoa 0x0002f917 rb_ffi_dispatch + >> 579 >> 10 com.apple.rubycocoa 0x000211ee objcptr_cptr + 1465 >> 11 com.apple.rubycocoa 0x000219c4 objcptr_cptr + 3471 >> 12 libruby.1.dylib 0x96092259 >> rb_with_disable_interrupt + 450 >> 13 libruby.1.dylib 0x9609a973 Init_eval + 17638 >> >> >> On 2007/02/23, at 3:45, Laurent Sansonetti wrote: >> >> >>> Hi guys, >> >>> >> >>> I added some better support for functions/methods dealing with C- >> >>> array >> >>> like arguments and/or return value, whose length isn't fixed and >> >>> depend on the context. >> >>> >> >>> Examples: >> >>> >> >>> CGColorRef CGColorCreate ( CGColorSpaceRef colorspace, const float >> >>> components[] ); >> >>> // 'components' length depends on the colorspace (it's the number of >> >>> colors + 1) >> >>> >> >>> const float *CGColorGetComponents ( CGColorRef color ); >> >>> // the return value also depends on the chosen colorspace >> >>> >> >>> Before it was necessary to deal with Array#pack, String#unpack and >> >>> OSX::ObjCPtr. >> >>> >> >>> Now you can also write: >> >>> >> >>> components = [0.1, 0.5, 0.9, 0] >> >>> color = CGColorCreate(CGColorSpaceCreateDeviceRGB(), components) >> >>> # (1) >> >>> components2 = CGColorGetComponents(color) # (2) >> >>> p components2[0] >> >>> >> >>> Technically, >> >>> >> >>> (1) RubyCocoa is now able to convert a Ruby array to this kind of >> >>> _C_PTR >> >>> (2) RubyCocoa has no way to know the size of the returned array, so >> >>> it >> >>> still returns an OSX::ObjCPtr object. But it's now possible to call >> >>> OSX::ObjCPtr#[] to retrieve arbitrary elements from the pointer. >> >>> >> >>> Of course, the user needs to be very careful when writing such code. >> >>> Passing a array of non-expected length and/or trying to access an >> >>> element at a non-expected index can crash the current application. >> >>> But >> >>> this kind of problems exist in C/ObjC too, and also with the >>> previous >> >>> way (using the packing functions). >> >>> >> >>> Laurent >> >>> _______________________________________________ >> >>> Rubycocoa-devel mailing list >> >>> Rubyc****@lists***** >> >>> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel >> >> _______________________________________________ >> Rubycocoa-devel mailing list >> Rubyc****@lists***** >> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel > > _______________________________________________ > Rubycocoa-devel mailing list > Rubyc****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel
