Bug 1442680 - gnome-shell killed by signal 11 during gnome initial setup
Summary: gnome-shell killed by signal 11 during gnome initial setup
Status: CLOSED DUPLICATE of bug 1443206
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 26
Hardware: x86_64
OS: Unspecified
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-04-17 06:07 UTC by Alessio
Modified: 2017-04-24 15:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-04-23 05:00:15 UTC
Type: Bug

Attachments (Terms of Use)
/var/spool/abrt/ccpp-2017-04-17-07:58:43.102495-737 (3.62 KB, text/plain)
2017-04-17 06:07 UTC, Alessio
no flags Details
Backtrace provided by the problem reporting utility (87.19 KB, text/plain)
2017-04-21 09:52 UTC, Joachim Frieben
no flags Details

Description Alessio 2017-04-17 06:07:55 UTC
Created attachment 1271977 [details]

Description of problem:

GNOME shell initial setup crash clicking Next on Privacy menu. User session exit. Login menu appear again. 

Version-Release number of selected component (if applicable):

Fedora 26 Branched 20170416.n.0


How reproducible:

Always, after logging in, try to complete gnome initial setup

Steps to Reproduce:
1. Login
2. Try to complete gnome initial setup

Actual results:

Process crash.

Expected results:

Configuration completes successful.

Additional info:

Cannot use automatic report (ABRT) because: Retrace server is unable to process package 'gnome-shell-3.24.1-1.fc26.x86_64'.

Apr 17 07:58:38 localhost.localdomain gnome-shell[2299]: gweather_location_unref: assertion 'loc->level != GWEATHER_LOCATION_WORLD' failed
Apr 17 07:58:38 localhost.localdomain audit[2299]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=2299 comm="gnome-shell" exe="/usr/bin/gnome-shell" sig=11 res=1

Comment 1 Joachim Frieben 2017-04-21 09:52:47 UTC
Created attachment 1273269 [details]
Backtrace provided by the problem reporting utility

The crash occurs when confirming the privacy settings suggested by gnome-initial-setup in a GNOME on Wayland session. On the contrary, in a GNOME on Xorg setting, the same action triggers the temporary blanking of the entire screen but after a short instant, the GNOME desktop reappears and gnome-initial-setup has moved successfully to the final page.

The output of command 'demesg' returns the error message:
gnome-shell[1411]: segfault at 38 ip 00007ffa270f12f4 sp 00007fffc1cf8540 error 4 in libgweather-3.so.6.6.0[7ffa270db000+2200

Unfortunately, the backtrace is reported to be unusable even when using local debuginfo files.

Comment 2 Joachim Frieben 2017-04-21 10:15:56 UTC
The backtrace is unusable because libicudata.so.57.1.debug has been built without debug info, see bug 1444427.

Comment 3 Alessio 2017-04-23 05:00:15 UTC

*** This bug has been marked as a duplicate of bug 1443206 ***

Comment 4 Michael Stahl 2017-04-24 10:39:15 UTC
(In reply to Joachim Frieben from comment #2)
> The backtrace is unusable because libicudata.so.57.1.debug has been built
> without debug info, see bug 1444427.

how did you get that idea?

Program terminated with signal SIGSEGV, Segmentation fault.
#0  _gweather_location_update_weather_location (gloc=0x0, loc=loc@entry=0x558c144a4e28) at gweather-location.c:1089
1089	gweather-location.c: No such file or directory.
[Current thread is 1 (Thread 0x7ffa8c5b8f80 (LWP 1411))]

   ^ that's where the segfault is

   the corresponding thread stack is Thread 1:

Thread 1 (Thread 0x7ffa8c5b8f80 (LWP 1411)):
#0  _gweather_location_update_weather_location (gloc=0x0, loc=loc@entry=0x558c144a4e28) at gweather-location.c:1089
        code = 0x0
        zone = 0x0
        yahoo_id = 0x0
        radar = 0x0
        tz_hint = 0x0
        country = 0x0
        latlon_valid = 0
        lat = 1.7976931348623157e+308
        lon = 1.7976931348623157e+308
        l = <optimized out>

the code is here:


so obviously "gloc=0x0" causes a null pointer dereference in
"if (gloc->level == GWEATHER_LOCATION_CITY && gloc->children)"
which is the immediate cause of the crash.

#1  0x00007ffa270e5ec6 in gweather_info_set_location_internal (info=<optimized out>, location=<optimized out>) at gweather-weather.c:2026
        priv = <optimized out>
        default_loc = <optimized out>
        name = 0x0
        latlon_override = 0
        lat = 0
        lon = 0


looking at the code the first parameter in this call:

    _gweather_location_update_weather_location (priv->glocation,

is set in line 2007: 

priv->glocation = location;

or in line 2023:

priv->glocation = gweather_location_find_by_station_code (world, station_code);

given that glocation is nullptr it must be the case that the function parameter "location=<optimized out>" (which gcc has optimized away at this point) was nullptr and the call to gweather_location_find_by_station_code returned nullptr.


gweather_location_find_by_station_code does a lookup by station_code and returns nullptr if there's no such station.

now we can't tell what the station_code was because that variable is no longer in scope at this point, but these variables are set by the same call that set station_code:

g_variant_get (default_loc, "(&s&sm(dd))", &name, &station_code, &latlon_override, &lat, &lon);

        name = 0x0
        latlon_override = 0
        lat = 0
        lon = 0

lat=0, lon=0 is on the equator in the atlantic ocean, there arent that many weather stations there presumably.

so in summary, this crashes because gweather_info_set_location is called with no weather station, and it fails to retrieve a valid "default" weather station; libicudata isn't involved anywhere.

Comment 5 Joachim Frieben 2017-04-24 14:42:01 UTC
(In reply to Michael Stahl from comment #4)
It appears that you analyze why this crash does actually happen and not why the backtrace is reported to be unusable by abrt which is the issue I was trying to raise.

Comment 6 Michael Stahl 2017-04-24 15:03:24 UTC
ah! sorry the ABRT problem wasn't obvious to me - so ABRT has a heuristic that
determines the backtrace is unusable? how does it do that? maybe it's
a bug in ABRT then, they might have a whitelist for special case libraries?
(they probably need to handle the vDSO specially?)

maybe reopen the ICU bug and assign it to ABRT to see if they have an idea if they can fix it on their end?

Note You need to log in before you can comment on or make changes to this bug.