#2650 closed defect (invalid)
Atlas crash on OSX Mavericks
Reported by: | wraitii | Owned by: | |
---|---|---|---|
Priority: | Must Have | Milestone: | Alpha 17 |
Component: | Atlas editor | Keywords: | osx atlas |
Cc: | Patch: |
Description (last modified by )
Atlas compiles successfully but crashes on startup (either from in-game or the command line). The error given is fairly weird in my case: [NSApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x103808b10
Update: I've done a lot of step-by-step debugging and in the end I think the culprit are the "[NSApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x102f22d70" errors I get.
I've tried de-threading the Scenario editor to see what the error was, and was still unable to get a window. This is because we never call the wxApp "OnInit" when starting the scenarioEditor. However ActorEditor does, and starts successfully. I've debugged this step by step, and it turns out the culprit is code at line 367 or utils.mm in src/osx/cocoa/, which was added in http://trac.wxwidgets.org/changeset/75142 after reports that non-bundled apps did not work anymore. Somehow, it fails with the above error, whereas actor editor doesn't. FYI, changing ActorEditor project to start ScenarioEditor does run OnInit, though that doesn't work since it lacks a few things. Still working on this.
Attachments (5)
Change History (23)
comment:1 by , 10 years ago
Description: | modified (diff) |
---|
comment:2 by , 10 years ago
by , 10 years ago
Attachment: | callstack1.rtf added |
---|
by , 10 years ago
Attachment: | callstack2.rtf added |
---|
comment:3 by , 10 years ago
Attached two. They are not 100% similar.
Xcode reports the crash in a slightly different place. I also get "segmentation fault: 11" in Terminal.
comment:4 by , 10 years ago
From those callstacks:
Thread 4 Crashed: 0 pyrogenesis 0x0000000107dcd8a1 ReloadChangedFiles() + 81 (Profiler2.h:154) 1 pyrogenesis 0x0000000107f0ae99 RunEngine(void*) + 1097 (Singleton.h:65) 2 libsystem_pthread.dylib 0x00007fff8d99f899 _pthread_body + 138 3 libsystem_pthread.dylib 0x00007fff8d99f72a _pthread_start + 137 4 libsystem_pthread.dylib 0x00007fff8d9a3fc9 thread_start + 13
Thread 8 Crashed: 0 pyrogenesis 0x000000010a1298a1 ReloadChangedFiles() + 81 (Profiler2.h:154) 1 pyrogenesis 0x000000010a266e99 RunEngine(void*) + 1097 (Singleton.h:65) 2 libsystem_pthread.dylib 0x00007fff8d99f899 _pthread_body + 138 3 libsystem_pthread.dylib 0x00007fff8d99f72a _pthread_start + 137 4 libsystem_pthread.dylib 0x00007fff8d9a3fc9 thread_start + 13
I initially guessed the new thread just wasn't calling g_Profiler2.RegisterCurrentThread
(so CProfiler2::GetThreadStorage
returned NULL), but it looks like it is :-( . Can you test if PROFILE2 works when called immediately after that? and if so, try to work out at what point it stops working, in case something is inexplicably resetting the TLS data. (But I don't see how that can happen.)
by , 10 years ago
Attachment: | call stack.txt added |
---|
by , 10 years ago
Attachment: | xcode callstac.png added |
---|
comment:5 by , 10 years ago
Okay, so the two earlier call stacks are useless, I had commented out "g_Profiler2.RegisterCurrentThread" and forgot to revert. I've provided the new one.
The behavior is hanging for a really long while with the [NSApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x102f22d70 error, and crashing thereafter. Attached callstack.
I've also attached xCode's debugging when the crash happens.
by , 10 years ago
Attachment: | crashlog2.txt added |
---|
comment:6 by , 10 years ago
added Another one that's more information-full, we get a crash when trying to create the CmdLineArgs object, something about n > max_size() throwing an error. It seems to me the cast goes wrong somehow.
It doesn't always happen that way though, which is odd.
comment:7 by , 10 years ago
After commenting the command line argument stuffs (which weren't needed) and some other code. I get EXC_BAD_INSTRUCTION with code EXC_I386_INVOP in random parts of that loop, unless I comment out the whole inner loop (starting with the while around l170).
It appears however I have no g_renderer nor any g_gui or similar.
If I try to run with -editor, it crashes with this:
[NSApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x7fcd50506a40 2014-07-06 22:36:41.045 pyrogenesis[12401:507] -[NSApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x7fcd50506a40 2014-07-06 22:36 pyrogenesis[12401] (CarbonCore.framework) FSEventStreamCreate: _FSEventStreamCreate: ERROR: could not allocate 0 bytes for array of path strings 2014-07-06 22:36 pyrogenesis[12401] (CarbonCore.framework) FSEventStreamScheduleWithRunLoop(): failed assertion 'streamRef != NULL' 2014-07-06 22:36 pyrogenesis[12401] (CarbonCore.framework) FSEventStreamStart(): failed assertion 'streamRef != NULL' dir_watch.cpp(143): Assertion failed: "0 && (L"event_loop FSEventStreamStart failed!")" 22:36:41: Error: Assertion failed: "0 && (L"event_loop FSEventStreamStart failed!")" Location: dir_watch.cpp:143 (CreateEventStream) Call stack: (error while dumping stack: Function not supported) errno = 0 (No error reported here) }}}
comment:8 by , 10 years ago
Description: | modified (diff) |
---|
Update: I've done a lot of step-by-step debugging and in the end I think the culprit are the "[NSApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x102f22d70" errors I get.
I've tried de-threading the Scenario editor to see what the error was, and was still unable to get a window. This is because we never call the wxApp "OnInit" when starting the scenarioEditor. However ActorEditor does, and starts successfully. I've debugged this step by step, and it turns out the culprit is code at line 367 or utils.mm in src/osx/cocoa/, which was added in http://trac.wxwidgets.org/changeset/75142 after reports that non-bundled apps did not work anymore. Somehow, it fails with the above error, whereas actor editor doesn't. FYI, changing ActorEditor project to start ScenarioEditor does run OnInit, though that doesn't work since it lacks a few things. Still working on this.
follow-up: 10 comment:9 by , 10 years ago
Cc: | removed |
---|---|
Priority: | Release Blocker → Must Have |
Resolution: | → invalid |
Status: | new → closed |
And as it turns out SDL is the culprit, moving to SDL 2.0.3 fixes the issue entirely and seamlessly. I'm going to close this and link to #2041.
Perhaps we should bump SDL2 support as a must have or a release blocker?
comment:10 by , 10 years ago
Replying to wraitii:
And as it turns out SDL is the culprit, moving to SDL 2.0.3 fixes the issue entirely and seamlessly. I'm going to close this and link to #2041.
Perhaps we should bump SDL2 support as a must have or a release blocker?
I forgot about this :/ This ticket sort-of duplicates #2427. I guess it's something that changed in Mavericks and broke SDL 1.2? I will make testing SDL2 on OS X my new priority.
comment:11 by , 10 years ago
comment:12 by , 10 years ago
Anyhow, SDL 2.0 did not fix the crash for me. It occurs on both Lion and Mavericks. I would be curious as to what wraitii's build config was such that it worked for him.
comment:14 by , 10 years ago
Based off current trunk I see this error in gdb when opening Atlas on Mavericks via the in-game menu:
2014-09-16 21:43:48.207 pyrogenesis_dbg[17478:d0b] -[NSApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x104824420 2014-09-16 21:43:48.364 pyrogenesis_dbg[17478:d0b] -[NSApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x104824420 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 17478 thread 0xc50b] 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x000000010090524b in RunEngine (data=0x7fff5fbfe5b8) at GameLoop.cpp:165 #2 0x00007fff850b3899 in _pthread_body () #3 0x00007fff850b372a in _pthread_start () #4 0x00007fff850b7fc9 in thread_start ()
The relevant line in GameLoop.cpp:165 is:
static void* RunEngine(void* data) { ... MessagePasserImpl* msgPasser = (MessagePasserImpl*)AtlasMessage::g_MessagePasser; ... { IMessage* msg; while ((msg = msgPasser->Retrieve()) != NULL) // <==== HERE { recent_activity = true; ...
And setting a breakpoint as follows, on the first iteration, confirms msgPasser->Retrieve() is null.
Breakpoint 1, RunEngine (data=0x7fff5fbfe5b8) at GameLoop.cpp:116 116 RegisterHandlers(); (gdb) p msgPasser $1 = (MessagePasserImpl *) 0x7fff5fbfcde0 Current language: auto; currently c++ (gdb) p msgPasser->Retrieve() 2014-09-16 21:59:18.196 pyrogenesis_dbg[17536:d0b] -[NSApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x10480cb70 $2 = ('AtlasMessage::IMessage' *) 0x0 (gdb) p msgPasser->IsEmpty() $3 = true
comment:15 by , 10 years ago
And the members of msgPasser at that point in time:
(gdb) p *((MessagePasserImpl *) 0x7fff5fbfcde0) $5 = { <AtlasMessage::MessagePasser> = { _vptr$MessagePasser = 0x103442f40 }, members of MessagePasserImpl: m_Mutex = { m_Mutex = { __sig = 1297437784, __opaque = "\000\000\000\000` ", '\0' <repeats 11 times>, "\002\000\000\000\002", '\0' <repeats 11 times>, "ο_?\000\000\004ο_?\000\000\000?z\004\001\000\000" } }, m_SemaphoreName = { <std::__1::basic_string<char>> = { <std::__1::__basic_string_common<true>> = {<No data fields>}, members of std::__1::basic_string<char>: static npos = <optimized out>, __r_ = { <std::__1::__libcpp_compressed_pair_imp<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__rep, std::__1::allocator<char>, 2>> = { <std::__1::allocator<char>> = {<No data fields>}, members of std::__1::__libcpp_compressed_pair_imp<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__rep, std::__1::allocator<char>, 2>: __first_ = { { __l = { __cap_ = 49, __size_ = 26, __data_ = 0x104876990 "/wfg-atlas-msgpass-979-718" }, __s = { { __size_ = 49 '1', __lx = 49 '1' }, __data_ = "\000\000\000\000\000\000\000\032\000\000\000\000\000\000\000?i?\004\001\000\000" }, __r = { __words = {49, 26, 4370950544} } } } }, <No data fields>} }, <No data fields>}, m_Semaphore = 0x5, m_Queue = { c = { <std::__1::__deque_base<AtlasMessage::IMessage *, std::__1::allocator<AtlasMessage::IMessage *> >> = { <std::__1::__deque_base_common<true>> = {<No data fields>}, members of std::__1::__deque_base<AtlasMessage::IMessage *, std::__1::allocator<AtlasMessage::IMessage *> >: static __block_size = <optimized out>, __map_ = { <std::__1::__split_buffer_common<true>> = {<No data fields>}, members of std::__1::__split_buffer<AtlasMessage::IMessage **, std::__1::allocator<AtlasMessage::IMessage **> >: __first_ = 0x0, __begin_ = 0x0, __end_ = 0x0, __end_cap_ = { <std::__1::__libcpp_compressed_pair_imp<AtlasMessage::IMessage ***, std::__1::allocator<AtlasMessage::IMessage **>, 2>> = { <std::__1::allocator<AtlasMessage::IMessage **>> = {<No data fields>}, members of std::__1::__libcpp_compressed_pair_imp<AtlasMessage::IMessage ***, std::__1::allocator<AtlasMessage::IMessage **>, 2>: __first_ = 0x0 }, <No data fields>} }, __start_ = 0, __size_ = { <std::__1::__libcpp_compressed_pair_imp<unsigned long, std::__1::allocator<AtlasMessage::IMessage *>, 2>> = { <std::__1::allocator<AtlasMessage::IMessage *>> = {<No data fields>}, members of std::__1::__libcpp_compressed_pair_imp<unsigned long, std::__1::allocator<AtlasMessage::IMessage *>, 2>: __first_ = 0 }, <No data fields>} }, <No data fields>} }, m_Trace = false }
comment:16 by , 10 years ago
Yeah, it also crashes for me when opened in-game (something in trompetin17's patch fixes that), does it work for you from the command line?
comment:17 by , 10 years ago
When run from the commandline I get a crash within a thread in the same location as above (in-game):
$ binaries/system/pyrogenesis_dbg -editor TIMER| LoadDLL: 4.60061 s 2014-09-17 07:43:02.086 pyrogenesis_dbg[47236:507] -[NSApplication transformToForegroundApplication]: unrecognized selector sent to instance 0x7f95604115a0 Segmentation fault: 11
Need a call stack or something, OS X actually generates pretty good reports on most crashes, I don't know if they work as well in Atlas. There's always a chance that it's another bug in wxWidgets, or something that changed in their init process from 2.9 to 3.0.