Bug #518422 “[MASTER] Firefox does not start with certain addons...” : Bugs : firefox package : Ubuntu

Revision history for this message

Draycen DeCator (ddecator) wrote on 2010-02-19:

#1

Thank you for taking the time to report this bug and helping to make Ubuntu better. Firefox 3.6 has gone through some updates since this bug was reported. Could you please update to the latest version and let us know if this problem is still affecting you?

Changed in firefox (Ubuntu):
status:	New → Incomplete

Revision history for this message

tromba-marina (tromba-marina) wrote on 2010-02-22:

#2

Same behaviour on Windows 7. You have to delete compatibility.ini every time Firefox is closed (or alternatively, start in safe mode, then restart into normal mode).
A lot more people seem to be encountering this problem on various operating systems, cf. http://support.mozilla.com/tiki-view_forum_thread.php?locale=de&forumId=1&comments_threshold=0&comments_parentId=562036.

My current build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6

Revision history for this message

Ryan (ubuntu-draziw) wrote on 2010-02-26:

#3

Folks on mozilla, ubuntu, xmarks (and other) forums reporting the same issue. Removing compatibility.ini before every launch allows firefox to launch correctly
http://ubuntuforums.org/archive/index.php/t-1386945.html

Changed in firefox (Ubuntu):
status:	Incomplete → Confirmed

Revision history for this message

Draycen DeCator (ddecator) wrote on 2010-03-01:

#4

Thank you for taking the time to find an upstream report for this bug. Just to make sure this is an upstream bug, can you please confirm that this is still occurring on the latest Firefox release? We would appreciate it if you could also run the following command in a terminal:

apport-collect 518422

This will add relevant information about your system to this report so we can make sure everything looks correct.

Revision history for this message

Ryan (ubuntu-draziw) wrote on 2010-03-01:

#5

You can find the apport data under https://bugs.launchpad.net/bugs/528139; apport-collect says you should only file on your bugs, or that you should create new and mark as dupe; since I already had a bug open, and already put in apport data, probably best to use that one.
ii firefox 3.6+nobinonly-0ubuntu5 safe and easy web browser from Mozilla
ii libxul-common 1.8.1.16+nobinonly-0ubuntu1 Gecko engine library - common files
ii libxul0d 1.8.1.16+nobinonly-0ubuntu1 Gecko engine library
ii xulrunner-1.9.1 1.9.1.8+build1+nobinonly-0u XUL + XPCOM application runner
If you really want me to attach to this one, let me know and I'll ignore the apport warning.

Revision history for this message

Draycen DeCator (ddecator) wrote on 2010-03-02:

#6

Sorry about that, I didn't realize that information was attached to the other report. Have you tried disabling the "Torbutton" add-on while in Safe Mode like Micah requested? If you could try that and let us know whether or not it works, we would appreciate it. Thanks in advance!

Revision history for this message

Ryan (ubuntu-draziw) wrote on 2010-03-02:

#7

Yes; Tried that. The 2 extensions I have that will consistently trigger the 'fail to even attempt launching' symptom (if compatibility.ini is in place) for me are RequestPolicy and xmarks. Both worked perfect on prior builds, and both work perfectly with 3.6 if I remove compatibility.ini, or if I launch in safe, enable, then click restart firefox. (which then runs without a compatibility.ini file)

Revision history for this message

Ryan (ubuntu-draziw) wrote on 2010-03-02:

#8

Download full text (3.6 KiB)

I tried a strace -f /usr/bin/firefox...

Looks like the issue ties to this read...
25377 read(3, 0xb7662058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
grep 0xb7662058 firefox-strace.txt |wc
425 4250 36975
Leading up to that read..
25377 socket(PF_FILE, SOCK_STREAM, 0) = 3
25377 connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
25377 getpeername(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, [20]) = 0
25377 uname({sys="Linux", node="lt", ...}) = 0
25377 access("/var/run/gdm/auth-for-ryan-D3btog/database", R_OK) = 0
25377 open("/var/run/gdm/auth-for-ryan-D3btog/database", O_RDONLY) = 4
25377 fstat64(4, {st_mode=S_IFREG|0600, st_size=47, ...}) = 0
25377 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb74d1000
25377 read(4, "\1\0\0\2lt\0\0010\0\22MIT-MAGIC-COOKIE-1\0\20\27"..., 4096) = 47
25377 read(4, "", 4096) = 0
25377 close(4) = 0
25377 munmap(0xb74d1000, 4096) = 0
25377 getsockname(3, {sa_family=AF_FILE, NULL}, [2]) = 0
25377 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
25377 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25377 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
25377 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
25377 writev(3, [{"l\0\v\0\0\0\22\0\20\0\0\0", 12}, {"", 0}, {"MIT-MAGIC-COOKIE-1", 18}, {"\0\0", 2}, {"\0273\203\3672'\0\367\360\375\" \377s\17\256", 16}, {"", 0}], 6) = 48
25377 read(3, 0xb7603a40, 8) = -1 EAGAIN (Resource temporarily unavailable)
25377 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
25377 read(3, "\1\0\v\0\0\0\3\3", 8) = 8
25377 read(3, "hX\243\0\0\0\340\3\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\0 \10\377\0\0\0\0"..., 3084) = 3084
25377 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
25377 writev(3, [{"b\0\5\0\f\0\0\0BIG-REQUESTS", 20}], 1) = 20
25377 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
25377 read(3, "\1\0\1\0\0\0\0\0\1\221\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
25377 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
25377 writev(3, [{"\221\0\1\0", 4}], 1) = 4
25377 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
25377 read(3, "\1\0\2\0\0\0\0\0\377\377?\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
25377 read(3, 0xb7662058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
25377 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
25377 writev(3, [{"7\0\5\0\0\0\340\3\255\1\0\0\10\0\0\0\377\377\377\0\24\0\6\0\255\1\0\0\27\0\0\0"..., 44}, {NULL, 0}, {"", 0}], 3) = 44
25377 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
25377 read(3, "\1\10\4\0,\0\0\0\37\0\0\0\0\0\0\0\255\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 208
25377 read(3, 0xb7662058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
25377 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
25377 writev(3, [{"b\0\5\0\t\0\340\3", 8}, {"XKEYBOARD", 9}, {"\0\0\0", 3}], 3) = 20
25377 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, rev...

I tried a strace -f /usr/bin/firefox...

Looks like the issue ties to this read...
25377 read(3, 0xb7662058, 4096)         = -1 EAGAIN (Resource temporarily unavailable)
grep 0xb7662058 firefox-strace.txt |wc
    425    4250   36975
Leading up to that read..
25377 socket(PF_FILE, SOCK_STREAM, 0)   = 3
25377 connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
25377 getpeername(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, [20]) = 0
25377 uname({sys="Linux", node="lt", ...}) = 0
25377 access("/var/run/gdm/auth-for-ryan-D3btog/database", R_OK) = 0
25377 open("/var/run/gdm/auth-for-ryan-D3btog/database", O_RDONLY) = 4
25377 fstat64(4, {st_mode=S_IFREG|0600, st_size=47, ...}) = 0
25377 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb74d1000
25377 read(4, "\1\0\0\2lt\0\0010\0\22MIT-MAGIC-COOKIE-1\0\20\27"..., 4096) = 47
25377 read(4, "", 4096)                 = 0
25377 close(4)                          = 0
25377 munmap(0xb74d1000, 4096)          = 0
25377 getsockname(3, {sa_family=AF_FILE, NULL}, [2]) = 0
25377 fcntl64(3, F_GETFL)               = 0x2 (flags O_RDWR)
25377 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
25377 fcntl64(3, F_SETFD, FD_CLOEXEC)   = 0
25377 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
25377 writev(3, [{"l\0\v\0\0\0\22\0\20\0\0\0", 12}, {"", 0}, {"MIT-MAGIC-COOKIE-1", 18}, {"\0\0", 2}, {"\0273\203\3672'\0\367\360\375\" \377s\17\256", 16}, {"", 0}], 6) = 48
25377 read(3, 0xb7603a40, 8)            = -1 EAGAIN (Resource temporarily unavailable)
25377 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
25377 read(3, "\1\0\v\0\0\0\3\3", 8)    = 8
25377 read(3, "hX\243\0\0\0\340\3\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\0  \10\377\0\0\0\0"..., 3084) = 3084
25377 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
25377 writev(3, [{"b\0\5\0\f\0\0\0BIG-REQUESTS", 20}], 1) = 20
25377 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
25377 read(3, "\1\0\1\0\0\0\0\0\1\221\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
25377 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
25377 writev(3, [{"\221\0\1\0", 4}], 1) = 4
25377 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
25377 read(3, "\1\0\2\0\0\0\0\0\377\377?\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
25377 read(3, 0xb7662058, 4096)         = -1 EAGAIN (Resource temporarily unavailable)
25377 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
25377 writev(3, [{"7\0\5\0\0\0\340\3\255\1\0\0\10\0\0\0\377\377\377\0\24\0\6\0\255\1\0\0\27\0\0\0"..., 44}, {NULL, 0}, {"", 0}], 3) = 44
25377 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
25377 read(3, "\1\10\4\0,\0\0\0\37\0\0\0\0\0\0\0\255\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 208
25377 read(3, 0xb7662058, 4096)         = -1 EAGAIN (Resource temporarily unavailable)
25377 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
25377 writev(3, [{"b\0\5\0\t\0\340\3", 8}, {"XKEYBOARD", 9}, {"\0\0\0", 3}], 3) = 20
25377 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
25377 read(3, "\1\0\5\0\0\0\0\0\1\223v\251\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
25377 read(3, 0xb7662058, 4096)         = -1 EAGAIN (Resource temporarily unavailable)

Just after the last unavailable (400+), firefox removes the 'lock' file in the profile dir.  I'd rather not attach the full strace since it has some personal bits from the profile - if a dev would like to review the output I'd be happy to provide it directly.

Revision history for this message

Ryan (ubuntu-draziw) wrote on 2010-03-02:

#9

So if I'm reading the trace right - the issue is with firefox not getting the read it expects from xwindows after trying to set permissions (MIT-MAGIC-COOKIE-1 being user based protection)
25377 writev(3, [{"l\0\v\0\0\0\22\0\20\0\0\0", 12}, {"", 0}, {"MIT-MAGIC-COOKIE-1", 18}, {"\0\0", 2}, {"\0273\203\3672'\0\367\360\375\" \377s\17\256", 16}, {"", 0}], 6) = 48
25377 read(3, 0xb7603a40, 8) = -1 EAGAIN (Resource temporarily unavailable)
and every read after that failing the same way. ??

Revision history for this message

Ryan (ubuntu-draziw) wrote on 2010-03-03:

#10

Replicated with nightly:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-firefox-3.6.x/firefox-3.6.2pre.en-US.linux-i686.tar.bz2
md5sum:
50e87e4dcbcf2dd5bed29e80c5ab1b4e firefox-3.6.2pre.en-US.linux-i686.tar.bz2

Revision history for this message

John Vivirito (gnomefreak) wrote on 2010-03-04:

#11

Changed to "triaged" as we have enough info for upstream to work on this

Changed in firefox (Ubuntu):
status:	Confirmed → Triaged

Revision history for this message

Micah Gersten (micahg) wrote on 2010-03-04:

#12

Marking High as this prevents usage

Changed in firefox (Ubuntu):
importance:	Undecided → High

Revision history for this message

Kees Cook (kees) wrote on 2010-03-04:

#13

A more stable work-around is:

rm compatibility.ini
ln -s /dev/null compatibility.ini

this will keep it worked around at every launch.

Revision history for this message

Kees Cook (kees) wrote on 2010-03-04:

#14

I take it back -- this causes GM to not initialize at all. An rm per run seems to fix it, though.

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-03-09:

#15

Bug 530196 is probably a symptom of this issue.

Another symptom may occur on linux builds where extensions containing components are symlinked. For example, on Debian, extensions can live in a common directory for all applications and /usr/lib/mozilla/extensions/{app-id}/{ext-id} is a symbolic link to the common directory.

Another trigger was reported by a user who uses symbolic links for his firefox profile.

What happens then is that while you can run firefox once, if you exit firefox and start it again, well, it doesn't start up.

It looks like the xptiInterfaceInfoManager part of bug 491245 is responsible for this issue. In other words, reverting its hunk (http://hg.mozilla.org/mozilla-central/diff/51bafb458d68/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp) is enough to "fix" the problem.

Revision history for this message

In Mozilla Bugzilla #551152, Bzbarsky (bzbarsky) wrote on 2010-03-09:

#16

So this is basically the same as bug 513736 and bug 530793, right?

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-03-09:

#17

(In reply to comment #1)
> So this is basically the same as bug 513736 and bug 530793, right?

Yes it is. And I think I know what the root problem is (though I am currently building to verify that), and it all boils down to what we want to expect from nsIFile.equals. In other words, the change in bug 491245 in probably very wrong, and the normalizations shouldn't even be needed.

On Unix, and I guess OSX, nsIFile.equals could be a matter of checking st_dev and st_ino in a stat() result.

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-03-09:

#18

Created an attachment (id=431372)
Possible patch, but fixing the wrong issue IMHO

I verified this patch works, for both the components directory issue and bug 530196 (tested after reverting it, too).

So the problem is that the normalization is done on the nsIFile contained in the components array, and this breaks some other code using this array.

Now, as I said in comment #2, I think the real issue is that of nsIFile.equals and should be fixed there. Patches for bug 530196 and bug 491245 should be reverted.

I can provide a patch for Unix. I guess the same logic would work on OSX.

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-03-09:

#19

Created an attachment (id=431403)
Patch

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-03-09:

#20

(From update of attachment 431403)
I'd be interested to know if the test passes on OSX with this patch.
It should, however, break on Windows.

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-03-09:

#21

Note this would probably be more efficient if the strcmp was done first and stat()s only done when then doesn't match. But I'd first like to hear what you think before going further.

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-03-09:

#22

http://msdn.microsoft.com/en-us/library/aa364952%28VS.85%29.aspx This could be used to implement the same test on Windows.

Revision history for this message

Micah Gersten (micahg) wrote on 2010-03-11: Re: Firefox does not start with certain addons installed

#23

Is everyone with this issue on amd64?

summary:

- Firefox does not start
+ Firefox does not start with certain addons installed

Revision history for this message

tekstr1der (tekstr1der) wrote on 2010-03-11:

#24

x86 here. I just rm -f compatibility.ini from the firefox launch script as a workaround for now, but that gets wiped on updates.

Micah Gersten (micahg) on 2010-03-11

tags:	added: regression-potential
Changed in firefox (Ubuntu):
milestone:	none → ubuntu-10.04-beta-2

Revision history for this message

Alexander Sack (asac) wrote on 2010-03-11:

#25

dont normalizepaths for xpti.dat Edit (1.1 KiB, text/plain)

seems its happening for extensions reachable through a link. The xpti management seems to normalize some paths, but not all, so it always thinks that xpti.dat isnt up to date meaning that it will refuse to start.

attachning patch.

Brian Murray (brian-murray) on 2010-03-11

tags:

added: patch

Revision history for this message

Dave Stroud (bigdavesr) wrote on 2010-03-12:

#26

The culprit on mine was prism. on x86. Simply disable it and it works fine.

Bryce Harrington (bryce) on 2010-03-12

Changed in firefox (Ubuntu Lucid):
assignee:	nobody → Canonical Desktop Team (canonical-desktop-team)

Rick Spencer (rick-rickspencer3) on 2010-03-12

Changed in firefox (Ubuntu Lucid):
assignee:	Canonical Desktop Team (canonical-desktop-team) → Chris Coulson (chrisccoulson)

Revision history for this message

In Mozilla Bugzilla #551152, Reed Loden (reed) wrote on 2010-03-16:

#27

Is there a reason you requested feedback instead of review from bsmedberg?

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-03-17:

#28

(In reply to comment #8)
> Is there a reason you requested feedback instead of review from bsmedberg?

Firstly because I'd like to hear which approach would be considered the right one. Secondly because the second patch is not complete, since it doesn't implement the change on windows and other platforms.

Revision history for this message

LordPhoenix (lorphoenix) wrote on 2010-03-23: Re: Firefox does not start with certain addons installed

#29

I've got same problem here with this message when launching from terminal :

Attempting to load the system libmoon
Segmentation fault (core dumped)

I've tried with a new firefox profile and got the problem only when I tried to use addons managment tools.

Hope this will help.

Revision history for this message

Chris Coulson (chrisccoulson) wrote on 2010-03-23:

#30

LordPhoenix - it seems that you have an unrelated issue

Revision history for this message

Ben Romer (bromer) wrote on 2010-03-23:

#31

I've just started having this problem after doing an update this morning. Removing the compatibility.ini works around the problem. I'm running the 64-bit Lucid beta.

Revision history for this message

Ben Romer (bromer) wrote on 2010-03-23:

#32

Also happening on 32-bit system after the same update.

Revision history for this message

Cody Herriges (ody-cat) wrote on 2010-03-23:

#33

Also affecting me after today's round of updates.

Revision history for this message

David Tester (david-g-tester) wrote on 2010-03-23:

#34

This bug hit me after pulling in today's updates. I'd been using Lucid Alpha 3 (32-bit). As suggested in comment #18, disabling Prism fixed it.

Revision history for this message

dtr (dtr) wrote on 2010-03-24:

#35

This bug is affecting me. I'm currently running Kubuntu 10.04 beta 64 bit.
Also with me Prism seems to be the culprit. After uninstalling Prism Firefox works again.

Revision history for this message

Mekk (marcin-kasperski) wrote on 2010-03-24:

#36

I have the same problem. Ubuntu 32-bit, up-to-date firefox (3.6+nobinonly-0ubuntu5~mfs~karmic1). Removing compatibility.ini helps (alternative way to resolve the problem is to start firefox in safe mode and quit it from the prompter, then start normally).

Revision history for this message

Mekk (marcin-kasperski) wrote on 2010-03-24:

#37

Looks like disabling prism helped.

Revision history for this message

Ben Romer (bromer) wrote on 2010-03-24:

#38

Removing prism made this problem go away on both my 32-bit and 64-bit systems.

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-03-25:

#39

*** Bug 533535 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-03-25:

#40

*** Bug 530793 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-03-25:

#41

*** Bug 513736 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #551152, Edouard KLEIN (edouard-jo-klein) wrote on 2010-03-25:

#42

Using the latest nightly build solves the problem. I deduce from that that the incoming version 3.6.3 will solve it as well.

Revision history for this message

Ryan (ubuntu-draziw) wrote on 2010-03-25: Re: Firefox does not start with certain addons installed

#43

Looks like the bug has been found, and is tracked under 551152, and fixed in the current nightly + will be GA in 3.6.3

Revision history for this message

Lord_JABA (lordjaba) wrote on 2010-03-25:

#44

After seeing the comments i probably just remove prism. Waiting for fix- i'm so used to use gmail+prism as my mail program

Bug Watch Updater (bug-watch-updater) on 2010-03-25

Changed in firefox:
status:	Unknown → Confirmed

Revision history for this message

Frank (fdmille) wrote on 2010-03-25:

#45

Yes, removing Prism worked for me too.

Revision history for this message

Mark Cariaga (mzc) wrote on 2010-03-25: Re: [Bug 518422] Re: Firefox does not start with certain addons installed

#46

the bug I submitted is not releated to prism. I have already remove
prism and prism-related application and still firefox does not open up.

On Thu, 2010-03-25 at 15:58 +0000, Lord_JABA wrote:
> After seeing the comments i probably just remove prism. Waiting for fix-
> i'm so used to use gmail+prism as my mail program
>

Revision history for this message

Mark Cariaga (mzc) wrote on 2010-03-25:

#47

After removing firefox, reboot, and reinstall, the bug has been fixed.
This also included removing prism.

On Thu, 2010-03-25 at 22:13 +0000, Frank wrote:
> Yes, removing Prism worked for me too.
>

Revision history for this message

John Vivirito (gnomefreak) wrote on 2010-03-25: Re: Firefox does not start with certain addons installed

#48

MZC:
What extension is causing problems for you?

Revision history for this message

John Vivirito (gnomefreak) wrote on 2010-03-25:

#49

Made this a master bug since it is the main report for same issue and it should be easier to locate when searching for it.

summary:

- Firefox does not start with certain addons installed
+ [MASTER] Firefox does not start with certain addons installed

Revision history for this message

Mark Cariaga (mzc) wrote on 2010-03-25: Re: [Bug 518422] Re: Firefox does not start with certain addons installed

#50

I installed google calendar (prism) after removing that program and
reinstalling firefox, i could not reproduce the bug anymore.

On Thu, 2010-03-25 at 22:35 +0000, John Vivirito wrote:
> MZC:
> What extension is causing problems for you?
>

Rick Spencer (rick-rickspencer3) on 2010-03-26

Changed in firefox (Ubuntu Lucid):
importance:	High → Medium

Revision history for this message

PEIGNOT Kévin (kpeignot) wrote on 2010-03-29:

#51

compatibility.ini Edit (159 bytes, text/plain)

Hi, I've this bug too, it never work. I discovered that if before starting fireofx I remove the .mozilla/firefox/dpr696di.default*compatibility.ini file, it start in the good way. I link a copy of this file. Maybe it's not due to the same bug I don't know

Revision history for this message

Carlos Joel Delgado Pizarro (c0x6a) wrote on 2010-03-29:

#52

I un-installed Prism from synaptic and Firefox start working normally again...
I always deleted the .mozilla folder at my home to have Firefox working, and now without Prism it works as nothing happened
I have Ubuntu 10.04beta1 amd64
Firefox 3.6+nobinonly-0ubuntu6

Revision history for this message

In Mozilla Bugzilla #551152, Mozilla-draziw (mozilla-draziw) wrote on 2010-03-29:

#53

Using the latest nightly 3.6.3pre did /not/ solve the problem for me.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-firefox-3.6.x/firefox-3.6.3pre.en-US.linux-i686.tar.bz2
(launched once since there was no compatibility.ini file - tried to re-launch, and it failed)

Revision history for this message

Henning Eggers (henninge) wrote on 2010-03-29: apport information

#54

Architecture: i386
DistroRelease: Ubuntu 10.04
EcryptfsInUse: Yes
FirefoxPackages:
firefox 3.6+nobinonly-0ubuntu6
firefox-gnome-support 3.6+nobinonly-0ubuntu6
firefox-branding 3.6+nobinonly-0ubuntu6
abroswer N/A
abrowser-branding N/A
Package: firefox 3.6+nobinonly-0ubuntu6
PackageArchitecture: i386
ProcEnviron:
LANGUAGE=de_DE:de:en_GB:en
PATH=(custom, user)
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-17.26-generic 2.6.32.10+drm33.1
Tags: lucid lucid
Uname: Linux 2.6.32-17-generic i686
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin netdev plugdev powerdev sambashare scanner video zope

tags:

added: apport-collected

Revision history for this message

Henning Eggers (henninge) wrote on 2010-03-29: Dependencies.txt

#55

Dependencies.txt Edit (3.2 KiB, text/plain)

apport information

Revision history for this message

Henning Eggers (henninge) wrote on 2010-03-29: ExtensionSummary.txt

#56

ExtensionSummary.txt Edit (654 bytes, text/plain)

apport information

Revision history for this message

Henning Eggers (henninge) wrote on 2010-03-29: profile_default_pluginreg.dat.txt

#57

profile_default_pluginreg.dat.txt Edit (3.7 KiB, text/plain)

apport information

Revision history for this message

Henning Eggers (henninge) wrote on 2010-03-29: profiles.ini.txt

#58

profiles.ini.txt Edit (94 bytes, text/plain)

apport information

Revision history for this message

Sini (jozsef-sin) wrote on 2010-03-30:

#59

Also un-installed Prism from synaptic and Firefox start working normally again...

Revision history for this message

Brandon (usbrandon) wrote on 2010-03-30:

#60

I am running the Lucid beta, did not see prism installed on my system.
Deleting the compatibility.ini file method is working for me.
I do have to keep deleting the compatibility.ini file each time after using Firefox or it will fail to launch next time.

Martin Pitt (pitti) on 2010-04-01

Changed in firefox (Ubuntu Lucid):
status:	Triaged → Fix Committed

Revision history for this message

Launchpad Janitor (janitor) wrote on 2010-04-01:

#61

This bug was fixed in the package firefox - 3.6.2+nobinonly-0ubuntu1

---------------
firefox (3.6.2+nobinonly-0ubuntu1) lucid; urgency=low

* New upstream release v3.6.2 (FIREFOX_3_6_2_RELEASE)

  [ Felix Geyer <email address hidden> ]
  * Rebase mozilla-kde.patch for 3.6.2
    - update debian/patches/mozilla-kde.patch

  [ Jamie Strandboge <<email address hidden> > ]
  * AppArmor profile cleanup for Lucid users:
    - remove sys_ptrace now that the kernel DTRT (LP: #498317)
    - don't use @{PROC}/[0-9]*/mounts or /etc/gnome/defaults.list (part of
      gnome abstraction now)
    - don't use @{PROC}/[0-9]*/maps (part of base abstraction)
    - don't use /etc/sound (part of audio abstraction)
    - use 'owner' for Desktop and all dot files and directories in @{HOME}
    - use ubuntu-bittorrent-clients abstraction
    - use ubuntu-media-players abstraction
    - allow access to xubuntu default app list (LP: #500231)
    - add ark and xarchiver for KDE and XFCE archive managers
    - add thunar for XFCE
    - add editors supported by It's All Text, thanks to James Troup
      (LP: #507711)
    - allow RealPlayer plugin and access to /usr/local/lib (LP: #501822)
    - allow Ux for scim and scim-bridge
    - allow ix for gst-plugin-scanner
  * ship different AppArmor profiles for different releases:
    - move usr.bin.firefox.apparmor.in to usr.bin.firefox.apparmor.9.10
    - add usr.bin.firefox.apparmor.10.04
    - debian/rules: ship AppArmor profile based on release:
      + add DISTRIB, DISTRIB_VERSION_MAJOR and DISTRIB_VERSION_MINOR
      + ship 9.10 profile for Karmic and under and 10.04 profile for Lucid
        and later
  * update AppArmor profile to transition to a java child profile rather
    than Ux. This has the added benefit of restricting java a bit more than
    before. This is needed since the java plugins are expecting certain
    environment variables to be present, which get scrubbed with Ux. 'cx'
    doesn't remove these from the environment but allows for better profiling
    over 'ux'. Thanks to John Johansen for discussion and idea. (LP: #484148)

  [ Alexander Sack <email address hidden> ]
  * fix LP: #518422 - Firefox does not start with certain addons installed;
    don't normalize paths for xpti.dat
    - add debian/patches/lp518422.patch
    - update debian/series

  [ Micah Gersten <email address hidden> ]
  * Bump minimum system NSS to 3.12.6 after upstream landing of (bmo: 545755)
    aka Update Mozilla stable branches to NSS 3.12.6 and minimal support for
    RFC 5746
    - update debian/rules
  * Really fix FTBFS for sparc; Add configure flag to correct variable
    - update debian/rules
-- Micah Gersten <email address hidden> Wed, 24 Mar 2010 01:17:46 -0500

This bug was fixed in the package firefox - 3.6.2+nobinonly-0ubuntu1

---------------
firefox (3.6.2+nobinonly-0ubuntu1) lucid; urgency=low

* New upstream release v3.6.2 (FIREFOX_3_6_2_RELEASE)

[ Felix Geyer <debfx-pkg@fobos.de> ]
  * Rebase mozilla-kde.patch for 3.6.2
    - update debian/patches/mozilla-kde.patch

[ Jamie Strandboge <jamie@ubuntu.com > ]
  * AppArmor profile cleanup for Lucid users:
    - remove sys_ptrace now that the kernel DTRT (LP: #498317)
    - don't use @{PROC}/[0-9]*/mounts or /etc/gnome/defaults.list (part of
      gnome abstraction now)
    - don't use @{PROC}/[0-9]*/maps (part of base abstraction)
    - don't use /etc/sound (part of audio abstraction)
    - use 'owner' for Desktop and all dot files and directories in @{HOME}
    - use ubuntu-bittorrent-clients abstraction
    - use ubuntu-media-players abstraction
    - allow access to xubuntu default app list (LP: #500231)
    - add ark and xarchiver for KDE and XFCE archive managers
    - add thunar for XFCE
    - add editors supported by It's All Text, thanks to James Troup
      (LP: #507711)
    - allow RealPlayer plugin and access to /usr/local/lib (LP: #501822)
    - allow Ux for scim and scim-bridge
    - allow ix for gst-plugin-scanner
  * ship different AppArmor profiles for different releases:
    - move usr.bin.firefox.apparmor.in to usr.bin.firefox.apparmor.9.10
    - add usr.bin.firefox.apparmor.10.04
    - debian/rules: ship AppArmor profile based on release:
      + add DISTRIB, DISTRIB_VERSION_MAJOR and DISTRIB_VERSION_MINOR
      + ship 9.10 profile for Karmic and under and 10.04 profile for Lucid
        and later
  * update AppArmor profile to transition to a java child profile rather
    than Ux. This has the added benefit of restricting java a bit more than
    before. This is needed since the java plugins are expecting certain
    environment variables to be present, which get scrubbed with Ux. 'cx'
    doesn't remove these from the environment but allows for better profiling
    over 'ux'. Thanks to John Johansen for discussion and idea. (LP: #484148)

[ Alexander Sack <asac@ubuntu.com> ]
  * fix LP: #518422 - Firefox does not start with certain addons installed;
    don't normalize paths for xpti.dat
    - add debian/patches/lp518422.patch
    - update debian/series

[ Micah Gersten <micahg@ubuntu.com> ]
  * Bump minimum system NSS to 3.12.6 after upstream landing of (bmo: 545755)
    aka Update Mozilla stable branches to NSS 3.12.6 and minimal support for
    RFC 5746
    - update debian/rules
  * Really fix FTBFS for sparc; Add configure flag to correct variable
    - update debian/rules
 -- Micah Gersten <micahg@ubuntu.com>   Wed, 24 Mar 2010 01:17:46 -0500

Changed in firefox (Ubuntu Lucid):
status:	Fix Committed → Fix Released

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-04-02:

#62

Benjamin, could you take a look ?

Revision history for this message

In Mozilla Bugzilla #551152, Hoyle-richard (hoyle-richard) wrote on 2010-04-02:

#63

The patch as in comment 5 (https://bugzilla.mozilla.org/attachment.cgi?id=431403)
works for me with symlinked home dirs. Otherwise ff fails to start on second
run. I can't seem to see that this patch has been pushed into the hg repo, though. If it has been, what branch was it pushed to?

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-04-02:

#64

Richard, it hasn't been applied, and hasn't been discussed. Patch in comment 5 also lacks corresponding change for Windows.

Revision history for this message

In Mozilla Bugzilla #551152, Hoyle-richard (hoyle-richard) wrote on 2010-04-02:

#65

This seems to have hit a lot of people and also seems to have
created a lot of unnecessary angst for extension writers. Does
the orig bug manifest at all under Windows? If not, wouldn't a
few ifdefs do to get this out of the door? Is a revert of
51bafb458d68 not acceptable either? Thanks for the patch, Mike!

Revision history for this message

PEIGNOT Kévin (kpeignot) wrote on 2010-04-05:

#66

I confirm, for me this bug is fixed

Revision history for this message

Flabdablet (flabdablet) wrote on 2010-04-18:

#67

Bug still present for me after updating to Firefox 3.6.3 (Ubuntu Hardy, using Firefox from Ubuntuzilla repo). Adding rm ~/.mozilla/firefox/*.default/compatibility.ini to /opt/firefox/firefox script right before run-mozilla.sh is launched works around it.

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-04-20:

#68

(From update of attachment 431372)
Let's try a different approach to get a comment on this.

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-04-20:

#69

(From update of attachment 431403)
I would be interested to know if you consider that to be the right approach. If so, I'll implement the win32 alternative and send to the try servers.

Revision history for this message

In Mozilla Bugzilla #551152, Neil-neilturner (neil-neilturner) wrote on 2010-04-30:

#70

Is there any way of encouraging someone with check-in powers to look at this? This bug is essentially preventing me from using most extensions in Firefox. I've voted for the bug, if that helps.

Revision history for this message

In Mozilla Bugzilla #551152, Reed Loden (reed) wrote on 2010-04-30:

#71

(In reply to comment #21)
> Is there any way of encouraging someone with check-in powers to look at this?

There's a patch waiting on review. Until the patch is given review, it cannot be checked-in.

Revision history for this message

In Mozilla Bugzilla #551152, Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote on 2010-04-30:

#72

I mentioned to mh on IRC, but this is on my list of things to really think about once 3.6.4 blockers and tracking are out of the way, but it might take a week or more yet.

Revision history for this message

Hilton Shumway (hillshum) wrote on 2010-05-04:

#73

Bug still present for me, but in Prism. I can't restart Prism without deleting compatibility.ini if xul-ext-gears is installed. A Gears xpi I manually installed works fine however. This is in Lucid

Revision history for this message

In Mozilla Bugzilla #551152, Untitled-titled (untitled-titled) wrote on 2010-05-05:

#74

Here is one topic about this bug on Mac OSX:

https://support.mozilla.com/en-US/forum/1/590191

Different solutions were offered though not clear (for me) which of them worked and why.

And one user on Mac OS X just installed Firefox (no add-ons, I guess) and has the same issue.

"I click on the icon on my dock for Firefox and it bounces up like other apps do when they start up, but then it just stops. it doesn't even show up on the activity monitor under active processes."

https://support.mozilla.com/en-US/forum/1/665803

Fix the problem in Firefox. And/or put a large link on support.mozilla.com about how to solve it.

Revision history for this message

In Mozilla Bugzilla #551152, Fox-nahunh (fox-nahunh) wrote on 2010-05-25:

#75

Hi from Germany,

same problem here. MacOS 10.6.3, FF 3.6.3. Very frustrating.

Plugins which will work:
Adblock Plus
Adblock Plus Element Hiding Helper
All-in-One Gestures
Counterpixel
Deutsches Wörterbuch
ebay Toolbar
Feed Filter
Fission
LiveClick
Long URL Please
NoScript
Quick Locale Switcher
QuickJava
ReloadEvery
TinEye Reverse
Trashmail.net
UrlbarExt
User Agent Switcher

Plugins which DONT WORK:
DownloadHelper
DownthemAll!
Greasemonkey
Modify Headers
Stylish
Weave

At least i've seen a couple of problems here with GreaseMonkey, Downthemall and
Weave. So what do these plugins have in common?

Revision history for this message

In Mozilla Bugzilla #551152, Mozilla-bigwillystyle42 (mozilla-bigwillystyle42) wrote on 2010-06-29:

#76

This now seems to work as expected on mozilla-central. I've got http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=33ff230a5b78&tochange=0d8bf91aa71e as the fix range, so maybe fixed by bug 570488 ?

Revision history for this message

In Mozilla Bugzilla #551152, Tom-malfrere (tom-malfrere) wrote on 2010-06-30:

#77

(In reply to comment #26)
> This now seems to work as expected on mozilla-central. I've got
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=33ff230a5b78&tochange=0d8bf91aa71e
> as the fix range, so maybe fixed by bug 570488 ?

OK, finally some positive news...
Is there a version (beta, rc, ...) available somewhere that we can test?

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-06-30:

#78

Please note that even if the current issue with the components directory is fixed, the PoC for trunk should still be considered as it also decreases the number of stat() calls at startup (normalization does a stat() on every sub directory of the path starting from / to see if it is a symbolic link and possibly resolve it). With this PoC, any call to file.normalize for use with file.equals could be removed.

Revision history for this message

In Mozilla Bugzilla #551152, Patrick-mozilla-enigmail (patrick-mozilla-enigmail) wrote on 2010-07-01:

#79

*** Bug 576233 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #551152, Mr-iopus (mr-iopus) wrote on 2010-07-02:

#80

>At least i've seen a couple of problems here with GreaseMonkey, Downthemall and
Weave. So what do these plugins have in common?

Do they use a XPT component? At least, that is what triggers the issue with our iMacros addon: https://bugzilla.mozilla.org/show_bug.cgi?id=574334
Renaming the xpt "solves" the issue (i. e. Firefox starts again, but the extension is broken)

Revision history for this message

In Mozilla Bugzilla #551152, Madcap (madcap) wrote on 2010-07-06:

#81

*** Bug 548927 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #551152, Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote on 2010-07-06:

#82

This was fixed completely on trunk (for Firefox 4) with bug 568691, and I don't think there is a safe patch I'd take on branches, so let's call this WORKSFORME.

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-07-07:

#83

(In reply to comment #32)
> This was fixed completely on trunk (for Firefox 4) with bug 568691, and I don't
> think there is a safe patch I'd take on branches, so let's call this
> WORKSFORME.

My patch for the 1.9.2 branch is pretty safe. Please consider it.

Other than that, what about comment 28 ? Need I file a new bug, now ?

Revision history for this message

In Mozilla Bugzilla #551152, Timeless-bemail (timeless-bemail) wrote on 2010-07-07:

#84

*** Bug 574458 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #551152, Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote on 2010-07-07:

#85

(From update of attachment 431372)
Yeah, that seems safe enough. r-d, this will help Linux (and mac) users whose application or profile is installed in a symlinked location, and is fairly low risk.

Revision history for this message

In Mozilla Bugzilla #551152, Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote on 2010-07-07:

#86

re: comment 28 followup, I don't think so: I'm pretty sure we aren't normalizing files at all any more.

Bug Watch Updater (bug-watch-updater) on 2010-07-07

Changed in firefox:
status:	Confirmed → Invalid

Revision history for this message

In Mozilla Bugzilla #551152, J-s-peatfield (j-s-peatfield) wrote on 2010-07-07:

#87

(In reply to comment #36)
> re: comment 28 followup, I don't think so: I'm pretty sure we aren't
> normalizing files at all any more.

Maybe not in mainline but the bug affects all 3.6.x releases.

Some of the bugs marked as duplicates of this one are reports against 3.6.x versions not trunk.

If every bug reported about this gets marked as a duplicate of this one then it just won't get fixed for 3.6.x...

Revision history for this message

In Mozilla Bugzilla #551152, J-s-peatfield (j-s-peatfield) wrote on 2010-07-07:

#88

(In reply to comment #37)
> (In reply to comment #36)
> > re: comment 28 followup, I don't think so: I'm pretty sure we aren't
> > normalizing files at all any more.
>
> Maybe not in mainline but the bug affects all 3.6.x releases.

Oops I can't read can I.

Revision history for this message

In Mozilla Bugzilla #551152, Timeless-bemail (timeless-bemail) wrote on 2010-07-07:

#89

*** Bug 574458 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #551152, Dveditz (dveditz) wrote on 2010-07-26:

#90

It probably makes the most sense to reopen this bug as a branch bug if we're going to try to land glandium's patch.

Revision history for this message

In Mozilla Bugzilla #551152, Dveditz (dveditz) wrote on 2010-07-26:

#91

*** Bug 530793 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #551152, Dveditz (dveditz) wrote on 2010-07-26:

#92

Comment on attachment 431403
Different approach for trunk

The trunk patch is obsolete if I'm reading comment 32 correctly.

Revision history for this message

In Mozilla Bugzilla #551152, Julian Sikorski (belegdol) wrote on 2010-07-26:

#93

This problem seems to be gone in Fedora Thunderbird 3.1.1 - I have both lightning and enigmail installed and enabled, and there are no problems launching. Is that expected?

Revision history for this message

In Mozilla Bugzilla #551152, Mozilla-bigwillystyle42 (mozilla-bigwillystyle42) wrote on 2010-07-27:

#94

(In reply to comment #43)
> This problem seems to be gone in Fedora Thunderbird 3.1.1 - I have both
> lightning and enigmail installed and enabled, and there are no problems
> launching. Is that expected?

I can't speak for the Fedora package, but the Thunderbird 3.1.1 from Mozilla still breaks because of this with Lightning.

Bug Watch Updater (bug-watch-updater) on 2010-07-27

Changed in firefox:
status:	Invalid → Confirmed

Revision history for this message

In Mozilla Bugzilla #551152, Antonin-roussel (antonin-roussel) wrote on 2010-07-30:

#95

This quickly neutralizes the bug for me (Linux Firefox, Sync Addon, symlinked profile)

$ firefox # runs OK
$ firefox --safe-mode # just exit in the safe-mode options prompt
$ firefox # runs OK

This command line as well
$ firefox --safe-mode && firefox

Revision history for this message

In Mozilla Bugzilla #551152, Clegnitto (clegnitto) wrote on 2010-08-02:

#96

Comment on attachment 431372
Possible patch for 1.9.2 branch

a=LegNeato for 1.9.2.9.

Revision history for this message

In Mozilla Bugzilla #551152, Bugzilla-standard8 (bugzilla-standard8) wrote on 2010-08-04:

#97

This bug broke xpcshell-tests on Mac on the 1.9.2 branch, see bug 584156.

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-08-04:

#98

(In reply to comment #47)
> This bug broke xpcshell-tests on Mac on the 1.9.2 branch, see bug 584156.

This doesn't make sense, because the patch doesn't change how registration is done.

Revision history for this message

In Mozilla Bugzilla #551152, Bugzilla-standard8 (bugzilla-standard8) wrote on 2010-08-04:

#99

(In reply to comment #48)
> (In reply to comment #47)
> > This bug broke xpcshell-tests on Mac on the 1.9.2 branch, see bug 584156.
>
> This doesn't make sense, because the patch doesn't change how registration is
> done.

Sorry, this could actually be bug 582012 - I missed checking the pushlog and didn't see it was pushed at the same time. I'm now building 1.9.2 and will confirm either way in a bit.

Revision history for this message

In Mozilla Bugzilla #551152, Bugzilla-standard8 (bugzilla-standard8) wrote on 2010-08-04:

#100

(In reply to comment #49)
> (In reply to comment #48)
> > (In reply to comment #47)
> > > This bug broke xpcshell-tests on Mac on the 1.9.2 branch, see bug 584156.
> >
> > This doesn't make sense, because the patch doesn't change how registration is
> > done.
>
> Sorry, this could actually be bug 582012 - I missed checking the pushlog and
> didn't see it was pushed at the same time. I'm now building 1.9.2 and will
> confirm either way in a bit.

Yep, local backout is showing that bug 582012 does indeed appear to be the culprit.

Revision history for this message

In Mozilla Bugzilla #551152, Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote on 2010-08-04:

#101

This landed and was backed out for the test failure.

Revision history for this message

In Mozilla Bugzilla #551152, Clegnitto (clegnitto) wrote on 2010-09-01:

#102

Comment on attachment 431372
Possible patch for 1.9.2 branch

Removing .9 approval as this missed landing before freeze. Feel free to nominate again, though the bar for approval will be higher.

Revision history for this message

In Mozilla Bugzilla #551152, J-s-peatfield (j-s-peatfield) wrote on 2010-09-01:

#103

Was the backout (of this patch) mentioned in comment 51 because the the "xpcshell-tests on Mac" problem which *seems* from the comments here to have been because of a different patch. Ie did this really break something despite what comments 48, 50 seem to imply?

The patch here doesn't seem to check if the Clone() succeeds so I suppose it might cause a problem on some systems assuming that Clone() needs to allocate memory.

Mind you I assume that Normalize() also might need to allocate memory if the resulting string is longer, I don't know if it can/will fail gracefully.

Apart from those the only thing which looks likely (IMHO) is just that it changes the memory layout slightly so maybe exposing a corruption problem somewhere else...

Does anyone have a simple test case showing a failure after applying the patch?

I wonder if changing the patch to call both current->Normalize() and normalized->Normalize() will show the same problem (not that such a patch would fix the problem that this bug was opened for, but it might be a test to see what is actually failing).

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-09-01:

#104

I don't know if Normalize() on mac can change things regarding case (since the fs is case insensitive), but if the failing test can vary depending on components directory case, that could be the source of the problem.

Revision history for this message

In Mozilla Bugzilla #551152, EricV (eric-valette) wrote on 2010-09-01:

#105

May I just remind you that whithout this patch, most linux distribution break as componen are indeed symlinked. So if ou do not add it upstream, mots distribution will ship it meaning that not landing it will be a failure. And BTW this cleraly indicates that the test plan should include symlinked components!

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-09-04:

#106

So, this is what can be seen on OSX debug builds with the patch applied:

###!!! ASSERTION: This is not supposed to fail!: 'Error', file /builds/slave/tryserver-macosx-debug/build/js/src/xpconnect/src/nsXPConnect.cpp, line 1017
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file /builds/slave/tryserver-macosx-debug/build/caps/src/nsScriptSecurityManager.cpp, line 3455

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-09-04:

#107

and what XPCOM_DEBUG_BREAK=stack-and-abort unveils:
DumpJSStack+0x00003B87 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x0004EF7B]
std::vector<unsigned short, std::allocator<unsigned short> >::resize(unsigned long)+0x0000429C [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x000461B2]
DumpJSStack+0x00039233 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x00084627]
std::vector<unsigned short, std::allocator<unsigned short> >::resize(unsigned long)+0x00008046 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x00049F5C]
DumpJSStack+0x0024756A [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x0029295E]
DumpJSStack+0x00251079 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x0029C46D]
DumpJSStack+0x00251666 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x0029CA5A]
DumpJSStack+0x002576DA [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x002A2ACE]
JNIEnv_::ThrowNew(_jclass*, char const*)+0x00063D7A [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x01185924]
NS_GetComponentRegistrar_P+0x00004046 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x011E67AE]
NS_GetComponentRegistrar_P+0x00005D09 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x011E8471]
JNIEnv_::ThrowNew(_jclass*, char const*)+0x00056CF9 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x011788A3]
JNIEnv_::ThrowNew(_jclass*, char const*)+0x0005720C [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x01178DB6]
DumpJSStack+0x00004E3E [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x00050232]
DumpJSStack+0x00004E98 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x0005028C]
DumpJSStack+0x000BCF53 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x00108347]
DumpJSStack+0x000C096C [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x0010BD60]
NS_GetComponentRegistrar_P+0x00004C3A [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x011E73A2]
NS_GetComponentRegistrar_P+0x0000715B [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x011E98C3]
NS_GetComponentRegistrar_P+0x000072BF [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x011E9A27]
NS_GetComponentRegistrar_P+0x0000780E [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x011E9F76]
NS_InitXPCOM3_P+0x000008D7 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x0118BEA7]
NS_InitXPCOM2_P+0x0000002F [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./XUL +0x0118BF41]
NS_InitXPCOM2+0x0000001F [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./libxpcom.dylib +0x000019DD]
start+0x00001601 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./TestRegistrationOrder +0x00001E31]
start+0x00000E7F [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./TestRegistrationOrder +0x000016AF]
start+0x000000FB [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./TestRegistrationOrder +0x0000092B]
start+0x00000029 [/Volumes/Namoroka/NamorokaDebug.app/Contents/MacOS/./TestRegistrationOrder +0x00000859]

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-09-05:

#108

Created attachment 472256
workaround for mac

So, I haven't found out (yet) what and why exactly, but what happens is that something on mac doesn't like that the components directory isn't normalized on mac. It's most probably related to bug 530188. The simplest "fix" I found is to normalize in nsDirectoryService::GetCurrentProcessDir (interestingly, the unix codepath uses realpath against MOZILLA_FIVE_HOME, so the patch makes it somewhat more close to what the unix codepath does).
This also explains why the test fails in the harness, where it is started as $BUILD_DIR/xpcom/tests/../../dist/bin/TestRegistrationOrder, and not when run by hand with $BUILD_DIR/dist/bin/TestRegistrationOrder. (running ./TestRegistrationOrder naturally fails, too)

Bug Watch Updater (bug-watch-updater) on 2010-09-13

Changed in firefox:
importance:	Unknown → Medium

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-09-29:

#109

Comment on attachment 472256
workaround for mac

We're too late for .11 but that could be considered for .12. The other patch attached to this bug was landed and led to bug 584156 on mac only, so it was backed out. This patch is an additional workaround for mac, which avoids bug 584156, according to my testing. This code is in a mac only part of the code so it doesn't affect anything but mac, and on mac, it may affect the value returned for the current process directory (depending on what exactly Normalize does on mac, and where Firefox is installed). This /shouldn't/ have an impact.

Revision history for this message

In Mozilla Bugzilla #551152, J-s-peatfield (j-s-peatfield) wrote on 2010-09-29:

#110

(In reply to comment #54)
> I don't know if Normalize() on mac can change things regarding case (since the
> fs is case insensitive)
...

Yes the default hfs+ setup on a Mac is case-insensitive but it isn't always the case.

If any code assumes that all Mac fs are case insensitive then it will break for those who choose to turn on the case-sensitive feature of hfs+ or for example where the files are mounted from a server with a protocol which is, such as smb or nfs.

[ not that this should be (hopefully) relevant to the bug... ]

Revision history for this message

In Mozilla Bugzilla #551152, Clegnitto (clegnitto) wrote on 2010-10-06:

#111

We're early in the development for .12 so I am willing to get this landed if it lands soon. If there are any issues we'll back it out, likely for good.

Revision history for this message

In Mozilla Bugzilla #551152, Clegnitto (clegnitto) wrote on 2010-10-06:

#112

a=LegNeato for 1.9.2.12. Please land only on the mozilla-1.9.2 default branch, *not* the relbranch.

Also, please be sure to land both patches (preferably as one patch).

Revision history for this message

In Mozilla Bugzilla #551152, Mh+mozilla (mh+mozilla) wrote on 2010-10-06:

#113

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5e114301d046

Bug Watch Updater (bug-watch-updater) on 2010-10-07

Changed in firefox:
status:	Confirmed → Fix Released

Revision history for this message

In Mozilla Bugzilla #551152, Martin-vogt (martin-vogt) wrote on 2010-10-08:

#114

Hello,

I had the same problem on SuSE Linux 11.1 with firefox 3.6.8.
After the second start with the add-ons "Firefox Sync",
downthemall or greasemonkey firefox directly terminates.

Here we use amd, not automount and the home directories are accessed
over a link.(The "bug" can be seen in the file xpti.dat.)

The two patches fixed the problems for me.

regards,

Martin

Revision history for this message

In Mozilla Bugzilla #551152, Vasilis Vasaitis (vvas) wrote on 2010-10-13:

#115

I built the "default" head of mozilla-1.9.2 yesterday and I can confirm that it fixes the problem for me too. Thanks!

Ubuntu
firefox package

[MASTER] Firefox does not start with certain addons installed

Bug Description

Related branches

Duplicates of this bug

Other bug subscribers

Patches

Bug attachments

Remote bug watches

Affects		Status	Importance	Assigned to	Milestone
	Mozilla Firefox	Fix Released	Medium	mozilla-bugs #551152
Nominated for 3.6 by Ryan
	firefox (Ubuntu)	Fix Released	Medium	Chris Coulson	Ubuntu ubuntu-10.04-beta-2
	Lucid	Fix Released	Medium	Chris Coulson	Ubuntu ubuntu-10.04-beta-2

Ubuntufirefox package

[MASTER] Firefox does not start with certain addons installed

Bug Description

Related branches

Duplicates of this bug

Other bug subscribers

Patches

Bug attachments

Remote bug watches

Ubuntu
firefox package