Last Comment Bug 551152 - Symlinked components break everything
: Symlinked components break everything
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: 1.9.2 Branch
: All Linux
: -- normal with 10 votes (vote)
: ---
Assigned To: Mike Hommey [:glandium]
:
Mentors:
: 513736 530793 533535 548927 574458 576233 (view as bug list)
Depends on: 584156
Blocks: 491245
  Show dependency treegraph
 
Reported: 2010-03-09 05:26 PST by Mike Hommey [:glandium]
Modified: 2010-12-03 00:42 PST (History)
36 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
.13-fixed
unaffected


Attachments
Possible patch for 1.9.2 branch (1.26 KB, patch)
2010-03-09 08:03 PST, Mike Hommey [:glandium]
benjamin: review+
christian: approval1.9.2.13+
christian: approval1.9.2.9-
Details | Diff | Review
Different approach for trunk (4.68 KB, patch)
2010-03-09 11:05 PST, Mike Hommey [:glandium]
no flags Details | Diff | Review
workaround for mac (1.06 KB, patch)
2010-09-05 06:10 PDT, Mike Hommey [:glandium]
benjamin: review+
christian: approval1.9.2.13+
Details | Diff | Review

Description Mike Hommey [:glandium] 2010-03-09 05:26:21 PST
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.
Comment 1 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-03-09 06:26:01 PST
So this is basically the same as bug 513736 and bug 530793, right?
Comment 2 Mike Hommey [:glandium] 2010-03-09 07:39:17 PST
(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.
Comment 3 Mike Hommey [:glandium] 2010-03-09 08:03:22 PST
Created attachment 431372 [details] [diff] [review]
Possible patch for 1.9.2 branch

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.
Comment 4 Mike Hommey [:glandium] 2010-03-09 11:05:38 PST
Created attachment 431403 [details] [diff] [review]
Different approach for trunk
Comment 5 Mike Hommey [:glandium] 2010-03-09 11:07:39 PST
Comment on attachment 431403 [details] [diff] [review]
Different approach for trunk

I'd be interested to know if the test passes on OSX with this patch.
It should, however, break on Windows.
Comment 6 Mike Hommey [:glandium] 2010-03-09 11:17:59 PST
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.
Comment 7 Mike Hommey [:glandium] 2010-03-09 11:20:00 PST
http://msdn.microsoft.com/en-us/library/aa364952%28VS.85%29.aspx This could be used to implement the same test on Windows.
Comment 8 Reed Loden [:reed] (use needinfo?) 2010-03-16 13:55:43 PDT
Is there a reason you requested feedback instead of review from bsmedberg?
Comment 9 Mike Hommey [:glandium] 2010-03-17 00:31:11 PDT
(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.
Comment 10 Mike Hommey [:glandium] 2010-03-25 01:31:25 PDT
*** Bug 533535 has been marked as a duplicate of this bug. ***
Comment 11 Mike Hommey [:glandium] 2010-03-25 01:32:50 PDT
*** Bug 530793 has been marked as a duplicate of this bug. ***
Comment 12 Mike Hommey [:glandium] 2010-03-25 01:33:17 PDT
*** Bug 513736 has been marked as a duplicate of this bug. ***
Comment 13 Edouard Klein 2010-03-25 01:54:30 PDT
Using the latest nightly build solves the problem. I deduce from that that the incoming version 3.6.3 will solve it as well.
Comment 14 Ryan 2010-03-29 16:31:28 PDT
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)
Comment 15 Mike Hommey [:glandium] 2010-04-02 01:05:58 PDT
Benjamin, could you take a look ?
Comment 16 Richard 2010-04-02 04:32:59 PDT
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?
Comment 17 Mike Hommey [:glandium] 2010-04-02 05:09:37 PDT
Richard, it hasn't been applied, and hasn't been discussed. Patch in comment 5 also lacks corresponding change for Windows.
Comment 18 Richard 2010-04-02 07:08:03 PDT
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!
Comment 19 Mike Hommey [:glandium] 2010-04-20 01:15:11 PDT
Comment on attachment 431372 [details] [diff] [review]
Possible patch for 1.9.2 branch

Let's try a different approach to get a comment on this.
Comment 20 Mike Hommey [:glandium] 2010-04-20 01:16:54 PDT
Comment on attachment 431403 [details] [diff] [review]
Different approach for trunk

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.
Comment 21 Neil Turner 2010-04-30 11:27:01 PDT
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.
Comment 22 Reed Loden [:reed] (use needinfo?) 2010-04-30 11:33:31 PDT
(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.
Comment 23 Benjamin Smedberg [:bsmedberg] 2010-04-30 11:45:22 PDT
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.
Comment 24 Wikiwide 2010-05-05 02:45:32 PDT
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.
Comment 25 fox_nahunh 2010-05-25 15:24:53 PDT
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?
Comment 26 Will Roberts [:bws42] 2010-06-29 18:08:44 PDT
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 ?
Comment 27 tom.malfrere 2010-06-30 04:33:05 PDT
(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?
Comment 28 Mike Hommey [:glandium] 2010-06-30 05:56:06 PDT
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.
Comment 29 Patrick Brunschwig 2010-07-01 23:42:48 PDT
*** Bug 576233 has been marked as a duplicate of this bug. ***
Comment 30 Mathias 2010-07-02 02:03:41 PDT
>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)
Comment 31 A Gaudio 2010-07-06 11:06:16 PDT
*** Bug 548927 has been marked as a duplicate of this bug. ***
Comment 32 Benjamin Smedberg [:bsmedberg] 2010-07-06 11:18:13 PDT
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.
Comment 33 Mike Hommey [:glandium] 2010-07-07 02:30:18 PDT
(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 ?
Comment 34 timeless 2010-07-07 02:56:33 PDT
*** Bug 574458 has been marked as a duplicate of this bug. ***
Comment 35 Benjamin Smedberg [:bsmedberg] 2010-07-07 05:50:15 PDT
Comment on attachment 431372 [details] [diff] [review]
Possible patch for 1.9.2 branch

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.
Comment 36 Benjamin Smedberg [:bsmedberg] 2010-07-07 05:51:05 PDT
re: comment 28 followup, I don't think so: I'm pretty sure we aren't normalizing files at all any more.
Comment 37 Jon Peatfield 2010-07-07 06:00:23 PDT
(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...
Comment 38 Jon Peatfield 2010-07-07 06:01:49 PDT
(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.
Comment 39 timeless 2010-07-07 06:52:29 PDT
*** Bug 574458 has been marked as a duplicate of this bug. ***
Comment 40 Daniel Veditz [:dveditz] 2010-07-26 15:04:20 PDT
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.
Comment 41 Daniel Veditz [:dveditz] 2010-07-26 15:05:16 PDT
*** Bug 530793 has been marked as a duplicate of this bug. ***
Comment 42 Daniel Veditz [:dveditz] 2010-07-26 15:07:22 PDT
Comment on attachment 431403 [details] [diff] [review]
Different approach for trunk

The trunk patch is obsolete if I'm reading comment 32 correctly.
Comment 43 Julian Sikorski 2010-07-26 15:09:25 PDT
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?
Comment 44 Will Roberts [:bws42] 2010-07-26 17:28:10 PDT
(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.
Comment 45 Tonin 2010-07-30 14:20:42 PDT
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
Comment 46 christian 2010-08-02 15:07:10 PDT
Comment on attachment 431372 [details] [diff] [review]
Possible patch for 1.9.2 branch

a=LegNeato for 1.9.2.9.
Comment 47 Mark Banner (:standard8) 2010-08-04 04:04:04 PDT
This bug broke xpcshell-tests on Mac on the 1.9.2 branch, see bug 584156.
Comment 48 Mike Hommey [:glandium] 2010-08-04 04:30:15 PDT
(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.
Comment 49 Mark Banner (:standard8) 2010-08-04 05:24:12 PDT
(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.
Comment 50 Mark Banner (:standard8) 2010-08-04 06:14:48 PDT
(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.
Comment 51 Benjamin Smedberg [:bsmedberg] 2010-08-04 12:24:07 PDT
This landed and was backed out for the test failure.
Comment 52 christian 2010-09-01 09:55:13 PDT
Comment on attachment 431372 [details] [diff] [review]
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.
Comment 53 Jon Peatfield 2010-09-01 12:26:11 PDT
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).
Comment 54 Mike Hommey [:glandium] 2010-09-01 12:33:15 PDT
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.
Comment 55 Eric Valette 2010-09-01 12:36:38 PDT
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!
Comment 56 Mike Hommey [:glandium] 2010-09-03 23:59:20 PDT
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
Comment 57 Mike Hommey [:glandium] 2010-09-04 00:02:24 PDT
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]
Comment 58 Mike Hommey [:glandium] 2010-09-05 06:10:22 PDT
Created attachment 472256 [details] [diff] [review]
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)
Comment 59 Mike Hommey [:glandium] 2010-09-29 07:33:17 PDT
Comment on attachment 472256 [details] [diff] [review]
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.
Comment 60 Jon Peatfield 2010-09-29 07:37:32 PDT
(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... ]
Comment 61 christian 2010-10-06 10:30:47 PDT
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.
Comment 62 christian 2010-10-06 10:32:50 PDT
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).
Comment 63 Mike Hommey [:glandium] 2010-10-06 10:52:46 PDT
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5e114301d046
Comment 64 martin.vogt 2010-10-08 07:42:33 PDT
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
Comment 65 Vasilis Vasaitis 2010-10-13 06:16:03 PDT
I built the "default" head of mozilla-1.9.2 yesterday and I can confirm that it fixes the problem for me too. Thanks!

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