Laurent Sansonetti
lsans****@apple*****
Fri Feb 23 21:58:53 JST 2007
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
