New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash on iOS and MacOS (?) in case-insensitive sorting #2094

Open
singalen opened this Issue Oct 10, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@singalen
Contributor

singalen commented Oct 10, 2017

Extracted from #1759 as a different problem.

Discussion from development Discord channel:
[19:53] sinda: Have exactly this problem on iOS: https://stackoverflow.com/questions/39809811/boost-locale-compare-throws-exc-bad-access
Strange, all the objects involved are non-null.

My stack is:


#0	0x0000000000000000 in 0x00000000 ()
#1	0x00000001014ed7f8 in boost::locale::collator<char>::compare(boost::locale::collator_base::level_type, char const*, char const*, char const*, char const*) const at /Users/vic/src/wesnoth/wesnoth/projectfiles/Xcode-iOS/battleforwesnoth/../lib/iOS_boost_1_60/libs/boost/include/boost/locale/collator.hpp:81
#2	0x00000001014ed788 in translation::icompare(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) at /Users/vic/src/wesnoth/wesnoth/src/gettext_boost.cpp:429
#3	0x00000001013830c4 in gui2::dialogs::campaign_selection::sort_campaigns(gui2::window&, gui2::dialogs::campaign_selection::CAMPAIGN_ORDER, bool)::$_1::operator()(std::__1::shared_ptr<ng::level> const&, std::__1::shared_ptr<ng::level> const&) const at /Users/vic/src/wesnoth/wesnoth/src/gui/dialogs/campaign_selection.cpp:149

@CelticMinstrel:

The trace from @singalen sounds like the same crash that I've gotten for awhile on the Mac when opening the file dialog (for example, go to map editor and click Load Map). Not sure if it's the same as that described in the opening post, but I recall @ancestral investigating a little and finding evidence of some binary compatibility issues between Boost and its dependencies (libiconv if I recall correctly) as the cause.

@singalen:

Might be the case. iOS version has access to two iconvs: Apple's version and GNU version. Sadly, glib and friends doesn't build on Apple iconv.

@CelticMinstrel:

If it is binary incompatibilities, it just means that the libraries @ancestral builds with need to be carefully tuned to require the correct version of the dependencies... which is easier said than done, mind you.

It doesn't crash for me on MacOS, only on iOS. I have Boost as a pre-built shared library in MacPorts.
Applying this workaround didn't help.

@mattsc

This comment has been minimized.

Show comment
Hide comment
@mattsc

mattsc Dec 9, 2017

Member

Confirming that this is happening for me (both the Campaigns -> Name and the Editor -> Load Game crashes) in macos 10.12 with both the 1.13.10 package and my own build of current master.
Marking as blocker.

Member

mattsc commented Dec 9, 2017

Confirming that this is happening for me (both the Campaigns -> Name and the Editor -> Load Game crashes) in macos 10.12 with both the 1.13.10 package and my own build of current master.
Marking as blocker.

@mattsc

This comment has been minimized.

Show comment
Hide comment
@mattsc

mattsc Dec 9, 2017

Member

Extracted from here:

I've done some more digging and found that the crash originates in https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/file_dialog.cpp#L96 when called from https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/file_dialog.cpp#L493.

That's for the editor crash. But I don't know what that means, what to do about it or even whether this is useful additional information here.

Member

mattsc commented Dec 9, 2017

Extracted from here:

I've done some more digging and found that the crash originates in https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/file_dialog.cpp#L96 when called from https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/file_dialog.cpp#L493.

That's for the editor crash. But I don't know what that means, what to do about it or even whether this is useful additional information here.

singalen added a commit to singalen/wesnoth that referenced this issue Dec 9, 2017

#2094 Work around a crash on a platforms with (supposedly) some Boost…
…/iconv incompatibility. Specifically, iOS and MacOS/XCode.

singalen added a commit to singalen/wesnoth that referenced this issue Dec 9, 2017

#2094 Work around a crash on a platforms with (supposedly) some Boost…
…/iconv incompatibility. Specifically, iOS and MacOS/XCode.
@singalen

This comment has been minimized.

Show comment
Hide comment
@singalen

singalen Dec 10, 2017

Contributor

@mattsc confirmed it's fixed.
Worked around. Probably it's something about static variables in statically linked libraries between gettext and boost::locale.

Contributor

singalen commented Dec 10, 2017

@mattsc confirmed it's fixed.
Worked around. Probably it's something about static variables in statically linked libraries between gettext and boost::locale.

@singalen singalen closed this Dec 10, 2017

jyrkive added a commit that referenced this issue Dec 10, 2017

#2094 Work around a crash on a platforms with (supposedly) some Boost…
…/iconv incompatibility. Specifically, iOS and MacOS/XCode.
@CelticMinstrel

This comment has been minimized.

Show comment
Hide comment
@CelticMinstrel

CelticMinstrel Dec 12, 2017

Member

Really not happy that the workaround is to sort case-sensitively, though.

Member

CelticMinstrel commented Dec 12, 2017

Really not happy that the workaround is to sort case-sensitively, though.

@singalen

This comment has been minimized.

Show comment
Hide comment
@singalen

singalen Dec 12, 2017

Contributor

For me, it was a quick fix that's definitely better than a crash in the field.

It should be doable to link Boost dynamically on MacOS. On iOS, it took me a royal pain to find a semi-working version and have it build and run. On top of that, can we enforce Boost::locale to be linked only as a shared library?

As for the other fix at SO... I think I might not have dug deep enough and gone through ALL the binaries that access Boost::locale. There should be a way to instantiate that singleton.

Contributor

singalen commented Dec 12, 2017

For me, it was a quick fix that's definitely better than a crash in the field.

It should be doable to link Boost dynamically on MacOS. On iOS, it took me a royal pain to find a semi-working version and have it build and run. On top of that, can we enforce Boost::locale to be linked only as a shared library?

As for the other fix at SO... I think I might not have dug deep enough and gone through ALL the binaries that access Boost::locale. There should be a way to instantiate that singleton.

@CelticMinstrel

This comment has been minimized.

Show comment
Hide comment
@CelticMinstrel

CelticMinstrel Dec 12, 2017

Member

I'm pretty sure Xcode is dynamically linking Boost though? And I know the error occurred in the Xcode build.

Now that it's at least not crashing, the priority has dropped, but we still need to fix this somehow. I guess it could wait until after 1.14 though. (Should we open a separate issue about it? Or reopen this? Or just keep posting on the closed issue?)

Member

CelticMinstrel commented Dec 12, 2017

I'm pretty sure Xcode is dynamically linking Boost though? And I know the error occurred in the Xcode build.

Now that it's at least not crashing, the priority has dropped, but we still need to fix this somehow. I guess it could wait until after 1.14 though. (Should we open a separate issue about it? Or reopen this? Or just keep posting on the closed issue?)

@singalen

This comment has been minimized.

Show comment
Hide comment
@singalen

singalen Dec 12, 2017

Contributor

Looks like that, but the crash is happening. Maybe on XCode it is DIFFERENT statically linked library, say, gettext? I don't build on Mac with XCode, so cannot tell.

My suggestion is to reopen the issue, as it has a meaningful history, and leave the workaround in.

Contributor

singalen commented Dec 12, 2017

Looks like that, but the crash is happening. Maybe on XCode it is DIFFERENT statically linked library, say, gettext? I don't build on Mac with XCode, so cannot tell.

My suggestion is to reopen the issue, as it has a meaningful history, and leave the workaround in.

@CelticMinstrel

This comment has been minimized.

Show comment
Hide comment
@CelticMinstrel

CelticMinstrel Dec 13, 2017

Member

Alright, will do.

I thought everything was dynamically linked in the Xcode build, but it's been quite awhile since I looked at it, so I could be remembering wrong.

Member

CelticMinstrel commented Dec 13, 2017

Alright, will do.

I thought everything was dynamically linked in the Xcode build, but it's been quite awhile since I looked at it, so I could be remembering wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment