unity8-dash crashed with SIGABRT in qt_message_fatal() under incorrect locale

[Michał Sawicz]

unity8-dash gets into a respawn loop when the selected locale is unavailable. While it's understood that incorrect locale might result in unexpected behaviour, but aborting feels excessive.

.log file mentions:

ERROR! Caught unity::scopes::ConfigException: Cannot instantiate run time for client, config file: :
    unity::scopes::MiddlewareException: cannot initialize zmq middleware for scope c-17178aae00000000:
        locale::facet::_S_create_c_locale name not

ProblemType: Crash
DistroRelease: Ubuntu 14.10
Package: unity8 8.00+14.10.20140828.1-0ubuntu1
Uname: Linux 3.4.0-5-mako armv7l
ApportVersion: 2.14.7-0ubuntu1
Architecture: armhf
CurrentDesktop: Unity
Date: Mon Sep 1 11:55:15 2014
ExecutablePath: /usr/bin/unity8-dash
ExecutableTimestamp: 1409258182
InstallationDate: Installed on 2014-09-01 (0 days ago)
InstallationMedia: Ubuntu Utopic Unicorn (development branch) - armhf (20140901-020204)
LocalLibraries: /android/system/lib/libGLES_trace.so /android/system/lib/libstlport.so /android/system/lib/libgccdemangle.so /android/system/lib/libm.so /android/system/lib/libcorkscrew.so /android/system/lib/liblog.so /android/system/lib/libstdc++.so /android/system/lib/libutils.so /android/system/lib/libc.so /android/system/lib/libcutils.so /android/system/lib/libGLESv2.so /android/system/lib/libEGL.so /android/system/lib/libdsyscalls.so
ProcCmdline: unity8-dash --desktop_file_hint=/usr/share/applications/unity8-dash.desktop
ProcCwd: /home/phablet
Signal: 6
SourcePackage: unity8
StacktraceTop:
 ?? () from /lib/arm-linux-gnueabihf/libc.so.6
 raise () from /lib/arm-linux-gnueabihf/libc.so.6
 abort () from /lib/arm-linux-gnueabihf/libc.so.6
 QMessageLogger::fatal(char const*, ...) const () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
 ?? () from /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqpa-ubuntumirclient.so
Title: unity8-dash crashed with SIGABRT in raise()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dialout dip plugdev sudo tty video

[Apport retracing service (apport)]

StacktraceTop:
 qt_message_fatal (context=..., message=...) at global/qlogging.cpp:1340
 QMessageLogger::fatal (this=this@entry=0xbec50224, msg=0xb4186f14 "UbuntuClientIntegration: connection to Mir server failed. Check that a Mir server is\nrunning, and the correct socket is being used and is accessible. The shell may have\nrejected the incoming connectio"...) at global/qlogging.cpp:669
 UbuntuClientIntegration::UbuntuClientIntegration (this=<optimized out>) at ../../../src/ubuntumirclient/integration.cpp:80
 UbuntuMirClientIntegrationPlugin::create (this=<optimized out>, system=...) at ../../../src/ubuntumirclient/plugin.cpp:36
 loadIntegration (argv=0xbec505e4, argc=@0x1: <error reading variable>, parameters=..., key=..., loader=0xb6f43058 <_ZZN12_GLOBAL__N_112Q_QGS_loader13innerFunctionEvE6holder>) at kernel/qplatformintegrationfactory.cpp:64

[Michał Sawicz (saviq)]

The retrace is unfortunately that of a different crash, but the difference is really just the error message as seen in the description.

Let me know if you need a real retrace of the problem in question

[Michi Henning (michihenning)]

I expect the exception comes out of the bowels of the glib ini parser. There is probably little that the scopes API can do, other than to maybe throw a separate exception for the parsing failure. But the shell should not try and initialize the run time without catching the exception and handling it a bit more gracefully.

How is it possible for a non-existent locale to be set in the first place? I would have thought that the UI should prevent that altogether?

[Jean-Baptiste Lallement (jibel)]

It happened this morning on krillin rc-proposed 202
https://errors.ubuntu.com/oops/55295946-a23a-11e5-a948-fa163e4aaad4

[Michi Henning (michihenning)]

I don't think scopes API can do anything here. It can't fiddle with the locale because that's a process-wide attribute.

We just propagate the exception up the caller, so the crash would appear to happen because the dash doesn't handle the exception when it initializes the runtime.

It seems this really is a unity8-dash bug?

[Michał Sawicz (saviq)]

unity-scopes-shell, rather

[Paweł Stołowski (stolowski)]

Ok, after discussing it on the standup we agreed that unity-scopes-shell should handle this exception and fallback to standard locale if the two conditions hold true:
- scopes api runtime initialization throws and
- current locale is not "" or "C" already

[Paweł Stołowski (stolowski)]

After trying to come up with a fallback for wrong locale I've to say this cannot be fixed at the point we hit the problem in unity-scopes-shell. It's already too late, and moreover there seem to be issues with the libstdc++ library when locale setup is broken and it's impossible to recover.

Related to this:
http://stackoverflow.com/questions/1745045/stdlocale-breakage-on-macos-10-6-with-lang-en-us-utf-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15467

When the locale setup is broken (which I can easily reproduce in my VM with only minimal ubuntu system with some locale settings pointing to non-existing PL locales, and LC_ALL is unset), all the locale-related C++ functions throw when trying to get current locale name and they also throw after trying to set LC_ALL to "C" at this point. In summary, these method calls throw:
std::locale("") (should get us current locale setup)
std::setlocale(LC_ALL, "C")
std::locale::global(std::locale::classic())

The only workaround I can think of is to avoid the crash, end up with a blank Dash page and log an error message to unity8-dash.log.
For the occasional problem with the tests we see when landing the package, I'll make sure LC_ALL=C when tests are executed.

[Paweł Stołowski (stolowski)]

And a new bug just reported by Michi against GCC with a minimal test case: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70493

[Timo Jyrinki (timo-jyrinki)]

I got this crash on my Pro 5 with OTA-11. Went back to the ubuntu dots animation.

[Paweł Stołowski (stolowski)]

Hi Timo, how did you manage to end up with a broken locale setup?

[Paweł Stołowski (stolowski)]

Also, can you attach unity8-dash.log when this happens? I wonder why you don't see a blank dash instead...

[Daniel van Vugt (vanvugt)]

This is still one of the top Unity8 crashes apparently...
https://errors.ubuntu.com/problem/bcb050f97778eb836056c1c48139bcde30ed0bcb

[Daniel van Vugt (vanvugt)]

Still #4 top Unity8 crash according to errors.ubuntu.com. And this is #2 of those that are still happening in 16.10.

[Paweł Stołowski (stolowski)]

Daniel, it seems that all bugs that end up in qFatal() fall into the same bucket.. The error you linked https://errors.ubuntu.com/problem/bcb050f97778eb836056c1c48139bcde30ed0bcb aborts because of Mir:

#4 QMessageLogger::fatal (this=0xb6410088 <lock>, this@entry=0xb6fa9000, msg=0xb4160e50 "UbuntuClientIntegration: connection to Mir server failed. Check that a Mir server is\nrunning, and the correct socket is being used and is accessible. The shell may have\nrejected the incoming connectio"...) at global/qlogging.cpp:636

[Daniel van Vugt (vanvugt)]

None of that is from the Mir source code :)

It just means Unity8 has gone AWOL, hence the dash can't find its Mir server any more.

[Daniel van Vugt (vanvugt)]

Priority bump just so this bug gets attention. Still the #1 Unity8 crash...

https://errors.ubuntu.com/?package=unity8&period=month

[Paweł Stołowski (stolowski)]

@Daniel I see your point about Mir. Anyway, all I'm saying is this problem manifested via https://errors.ubuntu.com/problem/bcb050f97778eb836056c1c48139bcde30ed0bcb is completely different from the original problem described in this bug. The only common thing is qFatal() gets called. In the original problem it was called directly by unity8-dash in response to boost throwing exception on incorrect locale (which was fixed by the attached MP). In this new case this is something else in the stack calling qFatal and aborting unity8-dash and I see no evidence of locale being involved.

To sum it up, I think it's a different bug and I don't think unity-scopes-shell (the dash) or unity-scopes-api are responsible for this.

[Albert Astals Cid (aacid)]

Yeah, it's a different issue altogether https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1655936

[Paweł Stołowski (stolowski)]

Marked this bug as duplicate of #1655936 to unconfuse errors.ubuntu.com (even though the bugs are technically different issues and the one from this bug was fixed long time ago).