Crash with "Call result #2 has unhandled type" trying to display a window

[trejkaz@…]

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.

[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.

[lsansonetti@…]

Assigning to Thibault who will look at this for the next beta.

[martinlagardette@…]

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.

[martinlagardette@…]

Fixed in revision [3149].

[martinlagardette@…]

[3149] fixes the crash. It doesn't make the original code work though... :-). Re-opening for further analyzis.

[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

[matthew@…]

Cc Me!

[lsansonetti@…]

Assigning to Rich for screening.

[martinlagardette@…]

If I remember correctly, the problem was an i386 bug with MacRuby, rather than HotCocoa. More specifically:

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.

[lsansonetti@…]

HotCocoa is no longer developed here. Please report the problem to  http://github.com/richkilmer/hotcocoa.