Closed Bug 981066 Opened 10 years ago Closed 10 years ago

XDG_CONFIG_DIRS=:::::: (7 directories listed / 6 separators) → Firefox segfaults (libc, libgtk), esp. on Ubuntu

Categories

(Toolkit :: Startup and Profile System, defect)

Product:
Toolkit
Component:
Startup and Profile System
Version:
28 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: guy.moore, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [bugday-20140310])

Crash Data

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140226081007

Steps to reproduce:

I don't know who would own this problem, but am logging this under
Firefox for now, and I also reported this bizarre behaviour to the
Ubuntu forums.

[cutting and pasting from here: http://ubuntuforums.org/showthread.php?t=2209804]

export XDG_CONFIG_DIRS=::::::; firefox;  causes a Segmentation fault 

My installation of 64-bit Lubuntu TrustyTahr Beta-1 (with current updates)

I cannot run `firefox` without getting:

Segmentation fault (core dumped).

After a bunch of divide and conquer, I got it narrowed down to the
XDG_CONFIG_DIRS variable that is set in the environment.

After a bunch of divide and conquer, I got it narrowed down to the
number of directories listed in that variable.
The values of the directories do not matter.
(I'm leaving them blank so as to not distract anyone)
If there are exactly 7 directories listed, firefox crashes.
Less than 7, or more than 7, firefox starts up.

These work:
export XDG_CONFIG_DIRS=:::::::; firefox; # 7 colons
export XDG_CONFIG_DIRS=:::::; firefox; # 5 colons

This does not:
export XDG_CONFIG_DIRS=::::::; firefox; # 6 colons

I can reproduce this on
64-bit Ubuntu TrustyTahr 14.04 LiveDVD burned with current build of 2014-03-02

I can NOT reproduce this on "32-bit" Lubuntu TrustyTahr 14.04 beta-1 with updates.
I can NOT reproduce this on 64-bit "PrecisePangolin" 12.04.4.

Can anyone add some insight on who or what product/library/file is causing the problem
so that I can log a bug in the appropriate product forum?

Can anyone else confirm this exact issue on "any" 64-bit TrustyTahr distribution so
I know it's not my specific machine/setup?

Thank you.

(side note: when running the liveDVD, XDG_CONFIG_DIRS only has 3 directories
listed at the time. So firefox works.
But after installation, etc., XDG_CONFIG_DIRS
has 7 directories listed, the magic number. So firefox fails.
The value of my XDG_CONFIG_DIRS after installation and logged in as me is:
/etc/xdg/lubuntu:/etc/xdg:/etc/xdg/lubuntu:/etc/xdg:/etc/xdg/xdg-Lubuntu:/usr/share/upstart/xdg:/etc/xdg
) 


Actual results:

Segmentation fault (core dumped).


Expected results:

Firefox should start up.
I can confirm it, I've checked influence of XDG_CONFIG_DIRS to FF's behaviour, as guy.moore@comcast.net wrote.

Earlier I confirmed bug at Lubuntu 14.04 TTx64 

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1278062

I can not prove neither system level nor application level fault, only the fact of relation between count of XDG_CONFIG_DIRS and FF's crash.
I've checked also on my current Arch Linux. 
$ uname -a
Linux xxx 3.13.5-1-ARCH #1 SMP PREEMPT Sun Feb 23 00:25:24 CET 2014 x86_64 GNU/Linux

The behaviour also presents.

$ export LANG=C
$ export XDG_CONFIG_DIRS=::::::;
$ firefox 

(process:2251): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Segmentation fault (core dumped)


But otherwise it runs successfully
 
$ export XDG_CONFIG_DIRS=:;
$ firefox 

(process:2257): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(firefox:2257): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(firefox:2257): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(firefox:2257): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(firefox:2257): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
bug: 2014-02-06-03-02-01-mozilla-central-firefox-30.0a1.ru.linux-x86_64 1e9f169c9715
WFM: 2014-02-07-03-02-01-mozilla-central-firefox-30.0a1.en-US.linux-x86_64 dedf12c4e805
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1e9f169c9715&tochange=dedf12c4e805

Seems to be fixed.  Please try with the latest Nightly from https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

Crash reports show no symbols; the penultimate line is about libgtk-x11-2.0.so.
Severity: normal → critical
Flags: needinfo?(guy.moore)
Keywords: crash
Whiteboard: [DUPEME][bugday-20140310]
I've tried with 

https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-30.0a1.en-US.linux-x86_64.tar.bz2

I've extracted it and run:

$uname -a
Linux xxx 3.13.6-1-ARCH #1 SMP PREEMPT Fri Mar 7 22:47:48 CET 2014 x86_64 GNU/Linux
$export XDG_CONFIG_DIRS=::::::;
$./firefox 

(process:2537): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Segmentation fault (core dumped)


It come with crash report to mozilla.org with details

BuildID: 20140310030201
CrashTime: 1394476667
InstallTime: 1394476415
ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
ProductName: Firefox
ReleaseChannel: nightly
SecondsSinceLastCrash: 223
You can find the crash report ids in about:crashes.
A little doubt: without -no-remote or MOZ_NO_REMOTE=1, Firefox started while another Firefox is running may try to just open a new window of the running instance.  Could it be that it did that, and the crash happened to the Nightly due to that window somehow?
Flags: needinfo?(guy.moore)
without any started instance of FF-nightly
$export XDG_CONFIG_DIRS=::::::;

$export MOZ_NO_REMOTE=1
https://crash-stats.mozilla.com/report/index/56fc942e-7b68-458e-8c5f-5469b2140311

$export MOZ_NO_REMOTE=0
https://crash-stats.mozilla.com/report/index/1be05cef-6bc9-45fe-b422-015082140311

The same with started instance
Component: Untriaged → General
I downloaded the build that Aleksej mentioned in comment#3.
I untarred it in /tmp and merely ran `cd /tmp/firefox; ./firefox`.
(not sure if I have to change any other environment variables)
Same exact behaviour as before in regards to the environment variable XDG_CONFIG_DIRS.
(although, when I do start firefox up successfully, I no longer have a menu bar in firefox, and it wanted to disable some add-ons.)
In other words, nothing was fixed.

Aleksej,
Which bug# did you think was fixed?
> (although, when I do start firefox up successfully, I no longer have a menu bar in firefox, and it wanted to disable some add-ons.)

The menu bar will be disabled by default.  When you start a Nightly, you should make a separate profile for it, e. g. with "-P".  Maybe it crashes because of your profile from the previous versions?

> Which bug# did you think was fixed?

I have no idea; I only found that builds before a certain day do crash, and builds since then don't.
Trying the same nightly build (as for my comment 2014-03-11 02:03:13 PDT)

$export XDG_CONFIG_DIRS=::::::;
$ ./firefox -P

(process:12213): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Segmentation fault (core dumped)

It crashes before profile selection
https://crash-stats.mozilla.com/report/index/e38262f3-8ef0-4043-876c-1e8522140313
Just now, Thursday 2014/03/13 9:00 AM, I burned a brand new
64-bit Ubuntu Trusty Tahr from Ubuntu's nightly build of March 13th, 2014,
and booted it up.
Firefox behaves exactly as described in my original posting.

I then, while that LiveDVD, was running, downloaded the March 13th, 2014 build
of firefox-30.0a1.en-US.linux-x86_64.tar.bz2 and ran that.
(meaning, i'm on a virgin machine, as a virgin user of "ubuntu")
Firefox behaves exactly as described in my original posting.

What else would you like me to do, to narrow down the problem any further
than what has already been described in my original posting?
Status: UNCONFIRMED → NEW
Crash Signature: @ libc-2.19.so@0x9044e
Ever confirmed: true
Summary: XDG_CONFIG_DIRS → XDG_CONFIG_DIRS=:::::: (6 colons) → Firefox segfaults (libc, libgtk), esp. on Ubuntu
Well, :Aleksej... Should it better transform "XDG_CONFIG_DIRS=:::::: (6 colons)" into "XDG_CONFIG_DIRS=:::::: (6 arguments|parametrs)" ? Otherwise the bug seems strange =)
Summary: XDG_CONFIG_DIRS=:::::: (6 colons) → Firefox segfaults (libc, libgtk), esp. on Ubuntu → XDG_CONFIG_DIRS=:::::: (6 directories listed) → Firefox segfaults (libc, libgtk), esp. on Ubuntu
Summary: XDG_CONFIG_DIRS=:::::: (6 directories listed) → Firefox segfaults (libc, libgtk), esp. on Ubuntu → XDG_CONFIG_DIRS=:::::: (7 directories listed / 6 separators) → Firefox segfaults (libc, libgtk), esp. on Ubuntu
This sounds a lot like bug 984445
See Also: → 984445
I've looked at bug 984445 and comments. A bit reminder aimed to narrow these facts: that's not "Ubuntu only" and not "pre-relise FF 28 builds from ubuntu PPAs"

$ uname -a
Linux xxx 3.13.6-1-ARCH #1 SMP PREEMPT Fri Mar 7 22:47:48 CET 2014 x86_64 GNU/Linux
$ pacman -Q | grep glibc
glibc 2.19-3
lib32-glibc 2.19-3
$pacman -Q | grep firefox
firefox 27.0.1-1

Then, facts to bug 984445
linux 3.13.6, glibc-2.19, x64
but:
Archlinux, FF 27.0.1
(In reply to Kolguev D. from comment #2)
> (firefox:2257): GLib-GObject-WARNING **: Attempt to add property
> GnomeProgram::sm-connect after class was initialised
> 
> (firefox:2257): GLib-GObject-WARNING **: Attempt to add property
> GnomeProgram::show-crash-dialog after class was initialised
> 
> (firefox:2257): GLib-GObject-WARNING **: Attempt to add property
> GnomeProgram::display after class was initialised
> 
> (firefox:2257): GLib-GObject-WARNING **: Attempt to add property
> GnomeProgram::default-icon after class was initialised

I started seeing these warnings after updating GLib from 2.36.4 to 2.38.2, but I'm not reproducing the segfault (on Gentoo), so the warnings may be unrelated.
(In reply to [:Aleksej] from comment #3)
I forgot to mention that the unregression range in comment #3 was found on Debian.
Whiteboard: [DUPEME][bugday-20140310] → [bugday-20140310]
:karlt Yes, I also suppose they are not related to, I'd just copy&paste console output. I was not aimed to focus developers on it, I've tried to reproduce the bug with  XDG_CONFIG_DIRS. Then, the crashlogs I've put below comment #2 and had tried to answer :Aleksej's questions about behavour of FF-nightly.
FYI:
Bug still exists as described in my original posting,
as of today, with the latest and greatest of all packages
including:
firefox 28.0+build2-0ubuntu1

On these platforms:
64-bit TrustyTahr Ubuntu 
and
64-bit TrustyTahr Lubuntu


I find it hard to understand some of the comments made above.
Is somebody unable to replicate the problem as described?
Did someone claim, it is not Firefox, but some other product?
Flags: firefox-backlog?
Component: General → Startup and Profile System
Product: Firefox → Toolkit
Flags: firefox-backlog?
The crash is under gdk_display_manager_set_default_display and appears to be outside of Firefox control.

I recommend that somebody do their own Firefox and get symbols for their glib/libc/libgtk to figure out what's actually crashing, but I'm about 99% certain it's not in Firefox code.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.