crash under OS X 10.9 when using the 10.9 Xcode build environment of Mavericks #15589
Comments
2013-10-18 00:30:54: @vadz changed status from new to closed2013-10-18 00:30:54: @vadz set resolution to fixed2013-10-18 00:30:54: @vadz commentedI think this was fixed by 74935, please apply this change locally and reopen if it doesn't help. In this case reproducing the problem in a sample would be very, very welcome too. |
2013-10-20 11:27:38: rocrail (Rob Versluis) changed status from closed to reopened2013-10-20 11:27:38: rocrail (Rob Versluis) changed resolution from fixed to **2013-10-20 11:27:38: rocrail (Rob Versluis) commentedIt did not solve the issue: |
2013-10-20 11:57:39: rocrail (Rob Versluis) commentedThe onInit is in this file: |
2013-10-20 13:01:40: @vadz commentedHmm, then I don't know what's going on here. It would help to have the debugging symbols for wx libraries (where exactly does it crash in Without more information I'm afraid there is not much we can do. |
2013-10-20 14:16:04: rocrail (Rob Versluis) commentedI suggest to let it rest until Mavericks is GA and test again because the same wx revision does not crash under OS X 10.8. |
2013-10-20 17:08:46: @csomor changed status from reopened to infoneeded_new2013-10-20 17:08:46: @csomor commentedwe need a reproducible case here, adding a static variable to minimal sample like this is executed normally, i.e. the stack trace looks similar - but no crash on my mac mini i7 QC running GM of 10.9 |
2013-10-25 06:44:25: rocrail (Rob Versluis) commentedIt only crashes if it is build under 10.9. A build from 10.8 runs normal. 2013-10-25 06:44:25: rocrail (Rob Versluis) changed status from infoneeded_new to new |
2013-10-25 06:51:42: rocrail (Rob Versluis) commentedThe configure command I use for building the wxWidgets library is: It is the same I use for OS X 10.8. |
2013-10-25 16:52:07: rocrail (Rob Versluis) changed priority from normal to blocker2013-10-25 16:52:07: rocrail (Rob Versluis) commentedStatus Quo:
The crash is still there. The backtrace does not even mention Rocrail classes… It happens just at startup before OnInit() is called. |
2013-10-25 17:16:25: @vadz changed status from new to infoneeded_new2013-10-25 17:16:25: @vadz commentedWe really need a way to reproduce this. It's impossible for us to debug the problems in all applications using wxWidgets (of which there are hundreds of thousands). Please try to [HowToSubmitPatches make a patch] to the minimal sample showing the problem. TIA! |
2013-10-25 17:46:19: rocrail (Rob Versluis) commentedOK, I will invest time to patch it into the minimal sample. |
2013-10-25 17:48:32: @vadz changed status from infoneeded_new to new2013-10-25 17:48:32: @vadz commentedYes, but if it doesn't happen in the minimal sample, it still must be due to something your application does -- and we don't know what. It's almost certainly relates to something being done in a global object ctor, but, again, I have no idea what exactly is it, only you can tell us. |
2013-10-25 17:59:51: rocrail (Rob Versluis) commentedI just provide an open source program in free time. |
2013-10-25 22:03:39: @csomor changed priority from blocker to normal2013-10-25 22:03:39: @csomor commentedI've rebuilt minimal sample with wx configured according your version under 10.9 (with my added static string as described above to trigger the wxGet_wxConvLocalPtr) and it didn't crash, but having conversions going on during static initialization is definitely not a too stable, this also triggers logging and apparently there strings don't seem to be ready in IsLevelEnabled ... |
2013-10-26 09:53:03: rocrail (Rob Versluis) changed status from infoneeded_new to new2013-10-26 09:53:03: rocrail (Rob Versluis) commentedI builded wxWidgets with debug enabled: |
2013-10-26 11:19:30: rocrail (Rob Versluis) commentedThe backtrace: |
2013-10-26 12:38:56: ericj commentedI don't work under OSX, so i'm not sure if i interpret the backtrace correctly. Set a breakpoint in wxApp::OnInit(). If the crash happens before the breakpoint is reached, it means that this code is executed before wxWidgets itself is initialized (= bad). You shouldn't have an instance of any wxWidgets class as global or static variable, because its ctor will be called before wxWidgets is initialized (it will be called even before main() ). Depending on the actual implementation of the class this may or may not work and should be avoided. If that's the case in your application (based on the callstack, "ImageLoader" might be a candidate), you should reorganize your code accordingly. |
2013-10-26 14:01:09: rocrail (Rob Versluis) commentedThe lldb is also new to me and I do not see any chance to step through the program... Which user call can trigger this class: |
2013-10-26 14:02:08: rocrail (Rob Versluis) commentedThe wxInitAllImageHandlers is in the OnInit method. |
2013-10-26 15:00:17: rocrail (Rob Versluis) commentedThe first source called is in the wxWidgets library: Without your help I can not fix this issue. |
2013-10-26 15:26:43: rocrail (Rob Versluis) commentedin object.cpp the last call: |
2013-10-26 15:29:18: ericj commentedI assumed ImageLoader was one of your classes, because i know it's not a wxWidgets class. But after googling it seems to be an OSX class and - based on the search results - seems to appear quite often in crash reports. So unfortunately i personally can't help with this, sorry for the noise. |
2013-10-26 17:38:02: @vadz commentedCheck that you don't use |
2013-10-27 07:53:00: rocrail (Rob Versluis) commentedThe value of str is not accessible which is the cause of the crash. |
2013-10-27 11:07:05: @vadz commentedBut where does it come from? I.e. try to go up the stack and check what's going on. Once again, in normal case it should be impossible for this value to be invalid and it's almost certainly due to something that you do with |
2013-10-27 11:15:42: rocrail (Rob Versluis) commentedI will try to add some printf's in the wx sources to tackle the class name involved. But I do not understand why it does not crash on OS X 10.8, and those builds also do not crash under OS X 10.9... |
2013-10-27 11:17:45: @vadz commentedI don't understand neither but this is just not a useful way to approach the problem. Clearly something has changed in the OS implementation details (I suspect it's something in the loader code). But we are not going to find what it was easily. OTOH it should be relatively easy to understand why does it crash now. And perhaps this will allow us to find what changed, too. Good luck! |
2013-10-27 11:26:29: rocrail (Rob Versluis) commentedThe only diff in this case is the compiler and linker. |
2013-10-27 13:58:22: rocrail (Rob Versluis) commentedI feel lost... |
2013-10-28 14:13:28: @vadz commentedFor any |
2013-10-28 14:16:14: ericj commented
BTW: I'm not 100% sure if the "invalid" pointer (this=0x00007fff5fbfdea0) i talked about in my previous post, is really invalid. It could be possible that the memory of the stack pointer "lives" in a different address range. Maybe some OSX expert could comment on this. |
2013-10-28 15:11:31: rocrail (Rob Versluis) commentedNo success. The crash is now in the archive class: |
2013-10-28 19:36:51: @oneeyeman1 commentedHi,
Do you free all memory you allocate? Thank you. |
2013-10-29 06:33:26: rocrail (Rob Versluis) commentedThis it at launching the application; No single line of code is backtraced of the user code, only wx. |
2013-10-29 06:35:00: rocrail (Rob Versluis) commentedThis is the build of Rocview: (Just one class changed.) |
2013-10-29 06:35:57: rocrail (Rob Versluis) commented06:29:46 **** Build of project Rocrail **** |
2013-10-29 18:42:26: rocrail (Rob Versluis) commentedI debugged a lot but as far as I can see it does not touch my code before the crash. |
2013-10-29 18:57:31: @oneeyeman1 commentedOk, so if you build wxWidgets with you configurationon the offending OS and then build minimal sample what happens? And what happens if you build propgrid or xti sample as suggested by Eric? If minimal sample does not crash, try putting the code from you Rockrail application into minimal sample line by line starting from the application/main frame constructor until it crashes. Also, since the crash is in different place when removed wxAny support: did you check that all pointers are freed? Did you run the program under valgrind? Do you use multi-threading? Do you do something GUI-related in a secondary thread? Thank you. |
2013-10-29 19:44:26: ericj commentedReplying to [comment:44 rocrail]:
If the crash can't be reproduced with any of the wx samples, the ball is on your side. It's very unlikely that someone takes your project, builds it and debugs it for you. I think it's pretty clear that the crash happens during the initialization of the global variables. a) Did you check if your project contains any global or static variables of complex classes? If you don't know, check your code. b) If a) is excluded as error source, you have to set a breakpoint before the crash, single step through the code and find out what exactly happens and why it happens. wxClassInfo::Register() in src/common/objecp.cpp would be my first guess. If i read the backtrace correctly, the crash should happen in this line: |
2013-10-29 20:33:07: @dconnet commentedReplying to [comment:46 ericj]:
I ran into an issue with global variables also (and static variables in functions) when I changed to using clang/xcode5. (static link) My removing all of those, I solved my issue. |
2013-10-29 22:46:12: rocrail (Rob Versluis) commented
Line by line? Impossible with this number of source code lines. Global and static variables are common and are sometimes needed/wanted. Again my status quo: All build on OS X 10.8 runs perfectly on OS X 10.9. All build on OS X 10.9 crash directly at initialising the static vars in the wx lib on OS X 10.9. All wx samples are very tiny and I did not yet tested them all. I set a break point in the wxApp main function but it crashes before at initialising statics in wxAny, wxArchive…. :( |
2013-10-29 23:45:01: paulclinger (Paul K) commented
As a workaround, how about building wxwidgets for your app with --with-macosx-version-min=10.8? You can keep 10.8 SDK on 10.9 and build against that SDK (I do this with my app as well to stay compatible with 10.6). |
2013-10-30 00:40:31: ericj commentedReplying to [comment:48 rocrail]:
That's too late, the crash happens earlier, even before main(). Like i said above, set a breakpoint in wxClassInfo::Register() in src/common/object.cpp |
2013-10-30 09:04:43: rocrail (Rob Versluis) commented
|
2013-10-30 09:20:28: @csomor commentedthe static initializer behaviour will not change by switching the SDK but only by switching the compiler, so I'd try copying an xcode4 to the 10.9 system and use its compilers for the command line builds |
2013-10-30 09:50:39: rocrail (Rob Versluis) commented
|
2013-10-30 10:17:11: rocrail (Rob Versluis) commentedThe complete debug session: |
2013-10-30 11:05:20: rocrail (Rob Versluis) commentedThe first part was missing in my prev. posting. |
2013-10-30 11:47:14: ericj commentedI'm pretty spoiled by visual debuggers, so i have a hard time reading this 80s output. But for me, everything boils down to the question: is 0x00007fff5fbfde88 a valid address in OSX address space? (Stefan?) If not, i would go as far as saying that this is a compiler bug. (but with all caution, as i'm not a OSX expert) |
2013-10-31 15:04:26: rocrail (Rob Versluis) commentedHow to proceed? |
2013-10-31 16:47:17: @vadz changed status from new to infoneeded_new2013-10-31 16:47:17: @vadz commentedI'm not sure at all it's a problem with Apple tools. And, anyhow, Apple is going to ask you to provide a minimal example reproducing the problem too. I'm sorry, I really don't know how to say it more clearly but you must reduce the problem. If you can't find the offending global ctor by just looking at your code, you will need to start removing global variables, one by one, until you find the one that causes the problem. Nobody but you can do this. Again, please feel free to ask for more details if this is unclear but it seems like you're just ignoring this repeatedly given piece of advice. Unfortunately I can't (or at least am not willing to) debug your application for you and I don't think there is anything else to do. |
2013-10-31 18:25:40: rocrail (Rob Versluis) changed status from infoneeded_new to new2013-10-31 18:25:40: rocrail (Rob Versluis) commentedThere are no global ctor's in my code; There is no reason for it to have any. I stepped with Eclipse and GBM through the process starting at launch under Linux(Ubuntu), and it never steps into a single Rocrail source line until the wxApp ctor which is never reached compiled and debugged under OS X 10.9. |
2013-10-31 18:59:58: @vadz commentedThere is obviously something in your code that triggers the bug as otherwise it would happen in the minimal sample too. If it's not a global variable, it may be something related to how you link, e.g. perhaps wx code gets linked twice, somehow. But there definitely is something specific to your program, that much seems clear. And even if it's not a bug per se, we still can't do anything about the real problem until we have some way of reproducing it not involving tons of code that we know nothing about. |
2013-11-16 21:09:28: rocrail (Rob Versluis) changed title from wxLog::IsLevelEnabled triggers crash under OS X 10.9 to crash under OS X 10.9 when using the 10.9 Xcode build environment of Mavericks |
2013-11-16 21:42:52: rocrail (Rob Versluis) commentedWhen I compile Minimal with following lines: It crashes: Backtrace: |
2013-11-16 21:51:08: rocrail (Rob Versluis) commentedWhy? I seen no diffs: |
2013-11-17 08:27:25: rocrail (Rob Versluis) changed status from new to closed2013-11-17 08:27:25: rocrail (Rob Versluis) changed resolution from ** to fixed2013-11-17 08:27:25: rocrail (Rob Versluis) commentedOK, tnx! Using: Solved the issue with minimal and also for Rocrail. |
Issue migrated from trac ticket # 15589
component: wxOSX | priority: normal | resolution: fixed
2013-10-17 11:07:04: rocrail (Rob Versluis) created the issue
I can run the minimal example on Mac OS X 10.9 Mavericks.
But after compiling my own application, which runs OK on Mac OS X 10.8 Mountain Lion, it crashes.
How can I fix this problem in my application?
std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_M_grab(std::allocator<wchar_t> const&, std::allocator<wchar_t> const&) + 4, queue'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x76fffffffc) frame #0: 0x00007fff889c108a libstdc++.6.dylibstd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_M_grab(std::allocator<wchar_t> const&, std::allocator<wchar_t> const&) + 4frame Fix NoneType Build Errors Crashs On Linux #1: 0x00007fff889c1656 libstdc++.6.dylib
std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) + 32 frame #2: 0x0000000100b47f24 libwx_osx_cocoau-3.0.dylibwxLog::IsLevelEnabled(unsigned long, wxString) + 84frame DVC Multiple sort column #3: 0x0000000100bf6afd libwx_osx_cocoau-3.0.dylib
wxCSConv::DoCreate() const + 61 frame #4: 0x0000000100bf8dea libwx_osx_cocoau-3.0.dylibwxGet_wxConvLocalPtr() + 106frame Update pt.po #5: 0x0000000100bfa9f3 libwx_osx_cocoau-3.0.dylib
_GLOBAL__I_a + 419 frame #6: 0x00007fff5fc11c2e dyldImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 268frame Merge pull request #1 from wxWidgets/master #7: 0x00007fff5fc11dba dyld
ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40 frame #8: 0x00007fff5fc0ea62 dyldImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 308frame Fix spelling of occur* in random files. #9: 0x00007fff5fc0e9eb dyld
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 189 frame #10: 0x00007fff5fc0e8f6 dyldImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 54frame Silenced gcc warnings for tests #11: 0x00007fff5fc021da dyld
dyld::initializeMainExecutable() + 189 frame #12: 0x00007fff5fc05560 dylddyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 2419frame Merge wxTaskBarButton into Core #13: 0x00007fff5fc0127b dyld
dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 477 frame #14: 0x00007fff5fc0105e dyld_dyld_start + 54The text was updated successfully, but these errors were encountered: