[MacRuby] #415: Crash with "Call result #2 has unhandled type" trying to display a window
#415: Crash with "Call result #2 has unhandled type" trying to display a window -----------------------------------+---------------------------------------- Reporter: trejkaz@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- I tried to run a trivial test application (straight from the MacRuby web page) and got a crash. I have narrowed down the cause in the Ruby code: {{{ require 'hotcocoa' include HotCocoa application do |app| win = window :size => [100,50] # commenting out this line makes it stay running end }}} I tried this on the 0.5 beta as well as the most recent nightly, getting the same result in both cases. Result of running this script: {{{ shard:test trejkaz$ macruby --version MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, i386] shard:test trejkaz$ macruby minimal.rb 2009-11-01 21:41:12.508 macruby[17009:903] *** -[NSLock unlock]: lock (<NSLock: 0x2214830> '(null)') unlocked when not locked 2009-11-01 21:41:12.512 macruby[17009:903] *** Break on _NSLockError() to debug. Call result #2 has unhandled type f32UNREACHABLE executed at CallingConvLower.cpp:148! Stack dump: 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@431' Abort trap }}} If this is really only happening to me, let me know what other information I can provide. -- Ticket URL: <http://www.macruby.org/trac/ticket/415> MacRuby <http://macruby.org/>
#415: Crash with "Call result #2 has unhandled type" trying to display a window -----------------------------------+---------------------------------------- Reporter: trejkaz@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- Comment(by lsansonetti@…): I reproduce the crash when running the script under i386 (32-bit Intel) mode. It looks like your computer is not 64-bit, therefore MacRuby runs 32-bit by default. I am sorry but 32-bit support is still not fully functional yet. We will try to address this problem in the upcoming release. -- Ticket URL: <http://www.macruby.org/trac/ticket/415#comment:1> MacRuby <http://macruby.org/>
#415: Crash with "Call result #2 has unhandled type" trying to display a window -----------------------------------+---------------------------------------- Reporter: trejkaz@… | Owner: martinlagardette@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- Changes (by lsansonetti@…): * owner: lsansonetti@… => martinlagardette@… * milestone: => MacRuby 0.5 Comment: Assigning to Thibault who will look at this for the next beta. -- Ticket URL: <http://www.macruby.org/trac/ticket/415#comment:2> MacRuby <http://macruby.org/>
#415: Crash with "Call result #2 has unhandled type" trying to display a window -----------------------------------+---------------------------------------- Reporter: trejkaz@… | Owner: martinlagardette@… Type: defect | Status: assigned Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- Changes (by martinlagardette@…): * status: new => assigned Comment: Still investigating, but some comments: I could reduce the code to the following: {{{ framework 'Cocoa' NSScreen.screens[0].visibleFrame }}} Using this also crashes: {{{ framework 'Cocoa' NSView.alloc.initWithFrame([0, 0, 10, 10]).frame }}} So apparently, the issue happens when NSRect is returned during 32 bits execution. On 64 bits, NSRect is aliased to CGRect, and CGFloats are doubles, instead of floats. The generated IR is a little different. -- Ticket URL: <http://www.macruby.org/trac/ticket/415#comment:3> MacRuby <http://macruby.org/>
#415: Crash with "Call result #2 has unhandled type" trying to display a window -----------------------------------+---------------------------------------- Reporter: trejkaz@… | Owner: martinlagardette@… Type: defect | Status: closed Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Changes (by martinlagardette@…): * status: assigned => closed * resolution: => fixed Comment: Fixed in revision [3149]. -- Ticket URL: <http://www.macruby.org/trac/ticket/415#comment:4> MacRuby <http://macruby.org/>
#415: Crash with "Call result #2 has unhandled type" trying to display a window -----------------------------------+---------------------------------------- Reporter: trejkaz@… | Owner: martinlagardette@… Type: defect | Status: reopened Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Resolution: Keywords: | -----------------------------------+---------------------------------------- Changes (by martinlagardette@…): * status: closed => reopened * resolution: fixed => -- Ticket URL: <http://www.macruby.org/trac/ticket/415#comment:5> MacRuby <http://macruby.org/>
#415: Crash with "Call result #2 has unhandled type" trying to display a window -----------------------------------+---------------------------------------- Reporter: trejkaz@… | Owner: martinlagardette@… Type: defect | Status: reopened Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Resolution: Keywords: | -----------------------------------+---------------------------------------- Comment(by martinlagardette@…): [3149] fixes the crash. It doesn't make the original code work though... :-). Re-opening for further analyzis. -- Ticket URL: <http://www.macruby.org/trac/ticket/415#comment:6> MacRuby <http://macruby.org/>
#415: Crash with "Call result #2 has unhandled type" trying to display a window -----------------------------------+---------------------------------------- Reporter: trejkaz@… | Owner: martinlagardette@… Type: defect | Status: reopened Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Resolution: Keywords: | -----------------------------------+---------------------------------------- Comment(by darkdescendant@…): I can confirm that the crash is stopped but the error message still remains. And this is on a 64 bit OS. I tried running the Postie example from the second tutorial. Here is the relevant crash info: Process: macruby [36083] Path: /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/bin/macruby Identifier: macruby Version: ??? (???) Code Type: X86-64 (Native) Parent Process: bash [36079] Date/Time: 2010-01-09 21:13:54.842 -0800 OS Version: Mac OS X 10.6.2 (10C540) Report Version: 6 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: objc[36083]: garbage collection is ON abort() called Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x00007fff81988fe6 __kill + 10 1 libSystem.B.dylib 0x00007fff81a29e32 abort + 83 2 libmacruby.dylib 0x000000010002962d rb_bug + 205 3 libmacruby.dylib 0x00000001000e3cee get_dyna_var_idx + 94 4 libmacruby.dylib 0x00000001000e867b iseq_compile_each + 7723 5 libmacruby.dylib 0x00000001000ee6a3 compile_array_ + 211 6 libmacruby.dylib 0x00000001000ee7ac compile_array + 12 7 libmacruby.dylib 0x00000001000ef935 setup_args + 549 8 libmacruby.dylib 0x00000001000ea820 iseq_compile_each + 16336 9 libmacruby.dylib 0x00000001000ecab1 iseq_compile_each + 25185 10 libmacruby.dylib 0x00000001000ecab1 iseq_compile_each + 25185 11 libmacruby.dylib 0x00000001000e9685 iseq_compile_each + 11829 12 libmacruby.dylib 0x00000001000e6b66 iseq_compile_each + 790 13 libmacruby.dylib 0x00000001000edcfb iseq_compile + 1243 14 libmacruby.dylib 0x00000001000f1a25 rb_iseq_new_with_bopt_and_opt + 133 15 libmacruby.dylib 0x00000001000f1a84 rb_iseq_new_with_opt + 20 16 libmacruby.dylib 0x00000001000f1be5 rb_iseq_compile_with_option + 277 17 libmacruby.dylib 0x0000000100126cbb Init_prelude + 123 18 libmacruby.dylib 0x00000001000bfadb process_options + 539 19 libmacruby.dylib 0x00000001000f83df rb_vm_call_cfunc + 175 20 libmacruby.dylib 0x00000001000bf250 ruby_process_options + 160 21 libmacruby.dylib 0x000000010002fa65 ruby_options + 133 22 macruby 0x0000000100000f17 main + 71 23 macruby 0x0000000100000ea4 start + 52 -- Ticket URL: <http://www.macruby.org/trac/ticket/415#comment:7> MacRuby <http://macruby.org/>
#415: Crash with "Call result #2 has unhandled type" trying to display a window -----------------------------------+---------------------------------------- Reporter: trejkaz@… | Owner: rich@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Resolution: Keywords: | -----------------------------------+---------------------------------------- Changes (by lsansonetti@…): * status: reopened => new * owner: martinlagardette@… => rich@… Comment: Assigning to Rich for screening. -- Ticket URL: <http://www.macruby.org/trac/ticket/415#comment:9> MacRuby <http://macruby.org/>
#415: Crash with "Call result #2 has unhandled type" trying to display a window -----------------------------------+---------------------------------------- Reporter: trejkaz@… | Owner: rich@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Resolution: Keywords: | -----------------------------------+---------------------------------------- Changes (by martinlagardette@…): * milestone: MacRuby 0.5 => Comment: If I remember correctly, the problem was an i386 bug with MacRuby, rather than HotCocoa. More specifically: {{{ #!ruby framework 'Cocoa' p NSMakeSize(400, 400) }}} {{{ $> arch -i386 macruby i386NaN.rb #<NSSize width=NaN height=NaN> }}} I think that's the one because that's what "window :size => [100,50]" does, and in the example, commenting this line makes the app work. -- Ticket URL: <http://www.macruby.org/trac/ticket/415#comment:10> MacRuby <http://macruby.org/>
participants (1)
-
MacRuby