firefox-3.5 crashed with SIGSEGV in __pthread_mutex_lock()

[Milan Bouchet-Valat]

Binary package hint: firefox-3.1

Crash fully reproducible when starting Shiretoko (appeared after a normal close, it was working nice until then). I don't know how to get rid of it... ;-)

UPDATE:
Happens when launched through Gnome Shell in Karmic, but only using Ubuntu builds, Mozilla Builds seem fine.

LAST VERSION TESTED:
Firefox 3.5.1

ProblemType: Crash
Architecture: i386
CrashCounter: 1
DistroRelease: Ubuntu 9.04
ExecutablePath: /usr/lib/firefox-3.1b3/firefox-3.1
Package: firefox-3.1 3.1~b3+build2+nobinonly-0ubuntu1
ProcCmdline: /usr/lib/firefox-3.1b3/firefox-3.1
ProcEnviron:
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
Signal: 11
SourcePackage: firefox-3.1
StacktraceTop:
 __pthread_mutex_lock (mutex=0xfeedbeef) at pthread_mutex_lock.c:51
 PR_Lock (lock=0xfeedbeef) at ptsynch.c:206
 ?? () from /usr/lib/xulrunner-1.9.1b3/libxul.so
 ?? () from /usr/lib/xulrunner-1.9.1b3/libxul.so
 ?? () from /usr/lib/xulrunner-1.9.1b3/libxul.so
Title: firefox-3.1 crashed with SIGSEGV in __pthread_mutex_lock()
Uname: Linux 2.6.28-11-generic i686
UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin plugdev sambashare vboxusers video

[Milan Bouchet-Valat (nalimilan)]

Actually, the bug only occurs when Shiretoko is started from the new experimental GNOME Shell, so that's a minor importance for now.

The code uses GAppInfo from GIO to start apps, here's the relevant extract, if it helps:
(this._appInfo is the GAppInfo to start)
    launch : function() {
        let global = Shell.Global.get();
        let screen = global.screen;
        let display = screen.get_display();
        let timestamp = display.get_current_time();
        let context = new Gdk.AppLaunchContext();
        let icon = this._appInfo.get_icon();
        context.set_icon(icon);
        context.set_timestamp(timestamp);
        this._appInfo.launch([], context);
    }

[Apport retracing service (apport)]

StacktraceTop:pthread_mutex_lock ()
PR_Lock (lock=0xfeedbeef) at ptsynch.c:206
XPCJSRuntime (this=0xb7933d00, aXPConnect=0xb79e2a50)
XPCJSRuntime::newXPCJSRuntime (aXPConnect=0xb79e2a50)
nsXPConnect (this=0xb79e2a50) at nsXPConnect.cpp:92

[Milan Bouchet-Valat (nalimilan)]

Now it's become more serious: it happens even when Shiretoko is started by standard ways, which means I'm no longer able to use it at all! So nothing related to GNOME Shell.

[Micah Gersten (micahg)]

Is this still occuring with Firefox 3.5b4 or later? Can you test with the latest daily build?
https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa

[Milan Bouchet-Valat (nalimilan)]

Yeah, confirmed with daily build 3.5~hg20090602r25850+nobinonly-0ubuntu1~umd1~jaunty.

[Milan Bouchet-Valat (nalimilan)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090603 Ubuntu/9.04 (jaunty) Shiretoko/3.5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090603 Ubuntu/9.04 (jaunty) Shiretoko/3.5pre

Shiretoko won't start when I'm running the new GNOME Shell. It always crashes on start before any window is shown. The interesting point is that after it has crashed, it won't start even if I switch from GNOME Shell back to the standard GNOME environment.

I'm using Ubuntu Jaunty with Firefox 3.5~hg20090603r25856. This bug has been occurring at least since March pre-releases of Shiretoko.

Full traces are available at:
http://launchpadlibrarian.net/24353332/Stacktrace.txt
http://launchpadlibrarian.net/24353333/ThreadStacktrace.txt

And the whole report in Launchpad is https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/348505. Please just ask if you need more information.

Reproducible: Always

[Tyler Downer (tyler-downer)]

uh, you are using the ubuntu distro of firefox, not ours. Please let them figure it out, if it turn out to be our problem, reopen this bug.

[Milan Bouchet-Valat (nalimilan)]

Upstream just closed the bug because they want to be sure that's not an Ubuntu bug (of which I doubt). Could somebody confirm?

[Micah Gersten (micahg)]

Is this still occurring with the release version?

[Milan Bouchet-Valat (nalimilan)]

Yeah, and even in the new development version. This bug should really get more care since it will refrain people from testing the new GNOME Shell that will be shipped in Karmic. And sooner or later, it will have to be fixed...

Actually, using the official Firefox 3.5 downloaded from Mozilla, I don't get the crash. Thay may be due to statically linked libraries though, not only to Ubuntu modifications.

[Micah Gersten (micahg)]

Please don't confirm your own bugs. I'm going to mark this Triaged as I believe that all information necessary is here. We might need a new crash, but that'll be up to the developer who looks at it.
Thank you for the updates.

[Alexander Sack (asac)]

Tyler, i hoped we are past the point where we just close bugs because they come from ubuntu. The user didn't say that it does not happen with the "official" upstream builds, so unless thats the case we want to keep bugs from ubuntu users open.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

This was last tested with Firefox 3.5.1 per user on Launchpad.

[Alexander Sack (asac)]

so this is gnome shell only? what is so special about it? maybe it sets some non-standard environment? or does something crazy with the X windows of started apps? Anyone can suggest a few differences?

Also please run firefox like: strace -f firefox-3.5 2>&1 | tee /tmp/ffox.log.txt and attach that file after reproducing the crash. thanks.

[Timeless-bemail (timeless-bemail)]

asac: sure we are, you're welcome to triage your bugs here.

we don't want to deal with useless or painfully long and horribly unreadable stack traces no matter who provides them. i just ignore someone else's inlined stack trace.

[Timeless-bemail (timeless-bemail)]

s/ignore/ignored/

reporter: try a mozilla.org build. if you can't reproduce the problem, then yell at asac.

[Milan Bouchet-Valat (nalimilan)]

Alexander: Not sure what the Shell does special. Since Shiretoko starts from terminal when running the Shell, and not when started when the Shell itself, I guess that's a problem with the why it launches it, and not with X; see my comment #2 about that. Also, once Shiretoko as failed starting, restarting it won't work even when the Shell is stopped. If you can give me some hints about the failure point, I may find out the problem, or ask the Shell's developers.

About upstream: as I said, the official build is working fine, but I guess it's using static libs, so that may not be significant. I'll post the strace log as soon as I can.

[Milan Bouchet-Valat (nalimilan)]

Seems to be gone, no idea if it's on Firefox's or GNOME's side...

[Milan Bouchet-Valat (nalimilan)]

Good news: the crash no longer happens. Using 3.5.3~hg20090813r26242+nobinonly-0ubuntu2~umd1~jaunty and GNOME Shell from git master. I hope that's not temporary...

[Milan Bouchet-Valat (nalimilan)]

FWIW now, here's an explanation a this bug, as explained by Colin Walters in gnome bug 592943:
> This is purely a gnome-shell --replace issue that just impacts
> developers/testers etc using jhbuild, but one of the side effects of using
> gnome-shell --replace inside jhbuild is that the jhbuild environment gets
> propagated into programs launched from the shell.
>
>A consequence of this is that we fail to launch firefox if it's linked against
> a different xulrunner.

1: http://bugzilla.gnome.org/show_bug.cgi?id=592943

[Timeless-bemail (timeless-bemail)]

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