[osx] Unable to start examples

[bgrzesik]

When I tried to launch examples(multiple), I got the following error messages.

$ cargo run --example threads
    Finished dev [unoptimized + debuginfo] target(s) in 0.3 secs
     Running `target/debug/examples/threads`
window::create(rect (0, 0, 1200, 900), flags 96, parent 0x0
window::create with flags 96
view 0x7f9722432bb0
view 0x7f9722432bb0 -> window 0x7f9722455140
fatal runtime error: allocator memory exhausted
[1]    981 illegal hardware instruction  cargo run --example threads

I have no idea why. I just wanted to learn this library using rust. I'm using macOS High Sierra 10.13.4, rustc 1.26.0-nightly (e5277c145 2018-03-28) and fresh sciter-sdk.

[pravic]

illegal hardware instruction

Could you tell about your CPU?

[bgrzesik]

I got the i7-7700HQ. After running some debugging, I found out that the error raises in msg_send! macro in https://github.com/sciter-sdk/rust-sciter/blob/50cb5385128cf1060d88b3b1e35d1505b6ccd37d/src/platform.rs#L398 Commenting out this line, causes error to raise in next msg_send!, commenting this one out causes no error and no sign of window at all.

[pravic]

I see.

Unfortunately, I don't have access to Mac at the moment. Could you run an example under gdb and show where the exception happens?

[bgrzesik]

I'm using lldb, but I guess it doesn't matter, and I guess you're asking me for the backtrace.

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x000000010274cb9a threads`alloc_system::platform::_$LT$impl$u20$alloc..allocator..Alloc$u20$for$u20$$RF$$u27$a$u20$alloc_system..System$GT$::oom::heeef4fe65bf8d016 at lib.rs:210 [opt]
    frame #1: 0x000000010274cb38 threads`_$LT$alloc_system..System$u20$as$u20$alloc..allocator..Alloc$GT$::oom::h992d4056b4518e18 at lib.rs:81 [opt]
    frame #2: 0x000000010272571c threads`__rde_oom at lib.rs:126 [opt]
    frame #3: 0x00000001027180a9 threads`_$LT$alloc..heap..Heap$u20$as$u20$alloc..allocator..Alloc$GT$::oom::h7a472a9c63ca68b0 at heap.rs:98 [opt]
    frame #4: 0x0000000102718093 threads`_$LT$alloc..raw_vec..RawVec$LT$T$C$$u20$A$GT$$GT$::reserve::hb75455b4594487d0 at raw_vec.rs:557 [opt]
    frame #5: 0x0000000102710ebf threads`_$LT$core..fmt..Write..write_fmt..Adapter$LT$$u27$a$C$$u20$T$GT$$u20$as$u20$core..fmt..Write$GT$::write_str::hd904ee64b026f3b2 [inlined] _$LT$alloc..vec..Vec$LT$T$GT$$GT$::reserve::hd863a6fad241e0c3 at vec.rs:465 [opt]
    frame #6: 0x0000000102710eb3 threads`_$LT$core..fmt..Write..write_fmt..Adapter$LT$$u27$a$C$$u20$T$GT$$u20$as$u20$core..fmt..Write$GT$::write_str::hd904ee64b026f3b2 [inlined] _$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$alloc..vec..SpecExtend$LT$$RF$$u27$a$u20$T$C$$u20$core..slice..Iter$LT$$u27$a$C$$u20$T$GT$$GT$$GT$::spec_extend::hf37b00edd2e3d685 at vec.rs:1857 [opt]
    frame #7: 0x0000000102710eb3 threads`_$LT$core..fmt..Write..write_fmt..Adapter$LT$$u27$a$C$$u20$T$GT$$u20$as$u20$core..fmt..Write$GT$::write_str::hd904ee64b026f3b2 [inlined] _$LT$alloc..vec..Vec$LT$T$GT$$GT$::extend_from_slice::h5ddebefc1c6d28f2 at vec.rs:1344 [opt]
    frame #8: 0x0000000102710eb3 threads`_$LT$core..fmt..Write..write_fmt..Adapter$LT$$u27$a$C$$u20$T$GT$$u20$as$u20$core..fmt..Write$GT$::write_str::hd904ee64b026f3b2 [inlined] alloc::string::String::push_str::ha42dca3ed83fe799 at string.rs:806 [opt]
    frame #9: 0x0000000102710eb3 threads`_$LT$core..fmt..Write..write_fmt..Adapter$LT$$u27$a$C$$u20$T$GT$$u20$as$u20$core..fmt..Write$GT$::write_str::hd904ee64b026f3b2 [inlined] _$LT$alloc..string..String$u20$as$u20$core..fmt..Write$GT$::write_str::h00583938950d86b9 at string.rs:2252 [opt]
    frame #10: 0x0000000102710eb3 threads`_$LT$core..fmt..Write..write_fmt..Adapter$LT$$u27$a$C$$u20$T$GT$$u20$as$u20$core..fmt..Write$GT$::write_str::hd904ee64b026f3b2 at mod.rs:214 [opt]
    frame #11: 0x00000001027088a2 threads`_$LT$alloc..string..String$u20$as$u20$core..fmt..Display$GT$::fmt::h04c63563e7572c93(self=0x00007ffeed51b318, f=0x00007ffeed51b138) at string.rs:1835
    frame #12: 0x0000000102708ef8 threads`_$LT$objc..message..MessageError$u20$as$u20$core..fmt..Display$GT$::fmt::h7f318d13cf7ea2ca(self=0x00007ffeed51b318, f=0x00007ffeed51b138) at mod.rs:157
    frame #13: 0x0000000102751019 threads`core::fmt::write::hb93881982b720b07 [inlined] core::fmt::Formatter::run::h97ea861a05d3fafa at mod.rs:1100 [opt]
    frame #14: 0x0000000102750e94 threads`core::fmt::write::hb93881982b720b07 at mod.rs:1047 [opt]
    frame #15: 0x0000000102712e64 threads`std::panicking::begin_panic_fmt::hd83639dd90ef02e7 [inlined] core::fmt::Write::write_fmt::hea62d9f289d5077e at mod.rs:226 [opt]
    frame #16: 0x0000000102712e29 threads`std::panicking::begin_panic_fmt::hd83639dd90ef02e7 at panicking.rs:348 [opt]
    frame #17: 0x0000000102707c80 threads`_$LT$sciter..platform..windows..OsWindow$u20$as$u20$sciter..platform..BaseWindow$GT$::expand::h4a05c37571d28e14(self=0x00007ffeed51b660, maximize=false) at platform.rs:395
    frame #18: 0x00000001026f5bf3 threads`sciter::window::Window::run_app::hd2bc702b5ccd9b30(self=Window @ 0x00007ffeed51b660) at window.rs:146
    frame #19: 0x00000001026eb90b threads`threads::main::ha834c9d248c32ee2 + 171
    frame #20: 0x00000001026e89b2 threads`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h980255dc4973fdf8 + 18
    frame #21: 0x0000000102712da8 threads`std::panicking::try::do_call::h91dbd433602e522c [inlined] std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::h775f8e3c04ef63f7 at rt.rs:59 [opt]
    frame #22: 0x0000000102712d9c threads`std::panicking::try::do_call::h91dbd433602e522c at panicking.rs:306 [opt]
    frame #23: 0x000000010272525f threads`__rust_maybe_catch_panic at lib.rs:102 [opt]
    frame #24: 0x00000001027117b2 threads`std::rt::lang_start_internal::h43e629aa9ae7be12 [inlined] std::panicking::try::h6d605b161eb4c1e2 at panicking.rs:285 [opt]
    frame #25: 0x000000010271177f threads`std::rt::lang_start_internal::h43e629aa9ae7be12 [inlined] std::panic::catch_unwind::hf13327c20348799e at panic.rs:361 [opt]
    frame #26: 0x000000010271177f threads`std::rt::lang_start_internal::h43e629aa9ae7be12 at rt.rs:58 [opt]
    frame #27: 0x00000001026e8992 threads`std::rt::lang_start::h9770017a58d1b9f3 + 66
    frame #28: 0x00000001026ecc75 threads`main + 37
    frame #29: 0x00007fff713e8015 libdyld.dylib`start + 1

[pravic]

So, illegal instruction was about core::intrinsics::abort and the source of the exception is in OsWindow::expand

https://github.com/sciter-sdk/rust-sciter/blob/50cb5385128cf1060d88b3b1e35d1505b6ccd37d/src/platform.rs#L395

Is really every msg_send! does not work? Or only activateIgnoringOtherApps?

Because the first one is NSApplication::sharedApplication here:

https://github.com/sciter-sdk/rust-sciter/blob/50cb5385128cf1060d88b3b1e35d1505b6ccd37d/src/platform.rs#L320

and it looks like it was passed fine.

[pravic]

And by the way, do apps from the Sciter SDK work?

[bgrzesik]

I don't think it's msg_send! macro itself, what causes the problem. I think it's rather activateIgnoringOtherApps and makeKeyAndOrderFront (cause it raised an error as well, when I commented the first one), because there is a third msg_send! in expand function and it didn't crash, after commenting the first two. I've tried running the demos and minimal from bin.osx directory and I succeeded, although I had to view the app content and run it directly from MacOS directory.

[pravic]

Ok, thanks.

I am getting an OSX 10.13.3 image to debug this issue.

[pravic]

It is strange, but it still works for me on macOS 10.13.3.

I've checked it under a VM which does not support OpenGL, so I had to switch to the CoreGraphics backend (see the interop.rs in 02948f8).

But, the #2 issue is still exists and, strangely enough, Python version does not have it.

I'll look on 10.13.4, may be.

[bgrzesik]

I've tried running interop with and without the arguments from the source file, but It still does the same.

[m-hilgendorf]

Possibly related to #14 :

I get this error when trying either of these (all other demos work fine):

$ cargo run --example dom
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/examples/dom`
window::create(rect (0, 0, 750, 950), flags 96, parent 0x0
window::create with flags 96
attached to None
view 0x7ff9cdd16630
view 0x7ff9cdd16630 -> window 0x7ff9cde04f10
view 0x7ff9cdd16630
view 0x7ff9cdd16630 -> window 0x7ff9cde04f10
warning! null element for HANDLE_BEHAVIOR_EVENT
Illegal instruction: 4

$cargo run --example download
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/examples/download`
window::create(rect (0, 0, 1024, 768), flags 96, parent 0x0
window::create with flags 96
view 0x7fa91bf103d0
view 0x7fa91bf103d0 -> window 0x7fa91be0a000
view 0x7fa91bf103d0
view 0x7fa91bf103d0 -> window 0x7fa91be0a000
warning! null element for HANDLE_BEHAVIOR_EVENT
Illegal instruction: 4

When running with the debugger attached this is the error:

  Referenced from: /Dev/rust-sciter/target/debug/examples/dom
  Reason: image not found 
  Signal: SIGABRT (signal SIGABRT)

Might this have something to do with the linker errors in #14?

[pravic]

Could you try debugger with cargo run --example download --features shared? It will try to load dylib dynamically.

And just to be sure: have you tried Sciter SDK examples to run? Do they work fine?

[m-hilgendorf]

Ok that fixed the linking issue, but I the crash down to line 318 of platform.rs when calling Window::create

fn get_app() -> *mut Object {
            let cls = Class::get("NSApplication").unwrap();
            let obj = unsafe { msg_send!(cls, sharedApplication) };
            return obj;
        }

Where calling Class::get returns None, causing the app to panic when it's unwrapped. This is due to this function at line 106 of runtime.rs returning a nullptr:

pub fn objc_getClass(name: *const c_char) -> *const Class;

And just to be sure: have you tried Sciter SDK examples to run? Do they work fine?

Yes.

[pravic]

Where calling Class::get returns None

Well, that is unexpected. How can it return None (nullptr, null, nil, whatever word we use for 0)?

nil if the class is not registered with the Objective-C runtime.

When NSApplication could not be registered yet at the beginning? I always thought that it is something that always exists (like argc, argv before main in C or HINSTANCE before WinMain in Windows).