541733 - greasemonkey causes startup failure on x64 builds if profile is on separate partition

Status: RESOLVED DUPLICATE of bug 513736

(Core :: XPCOM, defect)

Description

[Will Roberts [:bws42]]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20100123 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20100123 Minefield/3.7a1pre

I'm running Debian Lenny x64 with two partitions:
/     has the system and all the applications
/data has user data (profiles,music,etc)

If I have greasemonkey installed then after exiting Minefield all subsequent attempts to launch Minefield will fail. I can successfully start if I run in safe-mode or delete extensions.ini. Both of those will allow me to run Minefield once, then the next attempt will fail again.

This was introduced in the 20090710 m-c nightly which gives this regression range: (20090709 nightly must have crashed; it is not available)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=845fd6b1ef23&tochange=c4fe058e760c

This only happens with the 64bit build; a 32bit build has no issue with the profile being on a separate partition. The crash also happens if I copy my minefield installation to /data so it only matters if the profile is not on the root partition.

To reproduce on a clean profile:
1. Install greasemonkey and restart minefield.
2. Close Minefield.
3. Start Minefield (it won't)

Reproducible: Always

Comment 1

[timeless]

https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report

Comment 2

[Will Roberts [:bws42]]

Attachment: gdb output

I couldn't find debug symbols for the nightly linux x86_64 build so instead I built my own with debug symbols using the mozconfig file from the linux x84_64 nightly. I can see a ton of assertions that are failing, but when I ask gdb to give me the stack traces it says there's no stack.

Oh it's actually exiting, not crashing. Is there anything else I can provide?

Comment 3

[timeless]

###!!! ASSERTION: This is not supposed to fail!: 'Error', file nsXPConnect.cpp, line 1018
###!!! ASSERTION: Failed to initialize nsScriptSecurityManager: 'NS_SUCCEEDED(rv)', file nsScriptSecurityManager.cpp, line 3451

please see https://developer.mozilla.org/En/XPCOM_DEBUG_BREAK
I think XPCOM_DEBUG_BREAK=break would be a good choice. You're going to need to figure out why the thing that isn't supposed to fail ... failed.

Comment 4

[Will Roberts [:bws42]]

I haven't been very successful with the debugger, so I took a slightly different tack. I looked at all the changesets in the pushlog from my first comment, and only one of them jumped out as changing code I thought was related, http://hg.mozilla.org/mozilla-central/rev/51bafb458d68 for bug 491245

I reverted that patch locally (Linux part only), and I no longer get the crash!

I don't believe the changes to xpcom/io/nsLocalFileUnix.cpp had any affect on my system, so the culprit would be the Normalize() calls that were added to xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp

I'll see if I can figure out what might be going wrong there tomorrow.

Comment 5

[Will Roberts [:bws42]]

I think I may actually be hitting two bugs here.

1) The addition of Normalize() in xptiInterfaceInfoManager.cpp causes the directories in xpti.dat to be written out Normalize()d, but only if an extension has XPT files. So if I delete the 3 XPT files that come with greasemonkey I no longer trip this bug though I'm guessing I probably broke greasemonkey.

When the xpti.dat is read in xptiManifest.cpp the directories are compared via nsLocalFile->Equals() which fails because the one written to file was Normalize()d and the one in the working set was not. Normalizing the file prior to equals is likely the correct thing to do, and it causes my build to behave properly. (As does manually editing xpti.dat back to the non-Normalize()d path).

2) Once xptiManifest.cpp bails because any of the checks fail then I hit the next bug. With a Linux x86 build, things go fine regardless of where my profile is and how it is referenced. With an x64 build a profile on / is fine, but a profile on /data is not okay if it is symlinked from /.

Just to clarify the above point:
firefox -P test => fails because /home/will/.mozilla/firefox/<uid>.test is a symlink to /data/profiles/mozilla/firefox/<uid>.test
firefox -Profile /data/profiles/mozilla/firefox/<uid>.test => works

This also only happens if the Normalize() calls are present in xptiInterfaceInfoManager.cpp. Commenting those out restore correct behavior.

I'm not sure how the different partitions come into play here and why it doesn't affect an x86 build on my system. Simply having a symlink in the profile path is not enough to cause the failure, the symlink must go from / to /data. An absolute profile path that contains a symlink from /data to / seems to work fine.

I believe that adding Normalize() calls prior to Equals() in xptiInterfaceInfoManager.cpp, xptiManifest.cpp, and xptiWorkingSet.cpp will likely "fix" this issue for me the same way that commenting out the two Normalize() calls will, but I'm afraid that it may be hiding some other bug.