extension manager fails to recognize any extensions

RESOLVED WONTFIX

Status

()

Core
XPCOM
--
major
RESOLVED WONTFIX
12 years ago
3 years ago

People

(Reporter: Shane Caraveo, Assigned: Mark Mentovai)

Tracking

1.8 Branch
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

On OS X x86, MOZILLA_1_8_BRANCH (both current and going back as far as 5/11/2006), the extension manager is failing to load any of the installed extensions listed in extensions.ini.  

I've tracked this down to nsLocalFile::SetPersistentDescriptor which fails when validating the size of the data (see the comment "be paranoid about  whichhaving too few data"). 

I've forced the extension manager to recreate extensions.ini (by deleting extensions.* in the profile).  I also verified that what nsLocalFile::GetPersistentDescriptor generates is in fact what is in extensions.ini.

Commenting out that size verification causes the extensions to get properly loaded.

This is in Komodo, and our extensions load fine on OSX PPC, Linux and Windows.


Reproducible: Always
(Reporter)

Comment 1

12 years ago
cc'ing Josh since this is x86 osx only

Comment 2

12 years ago
I remember hearing some comments from the last WWDC about how AliasRecord or something closely related to it was a common x86 transition problem. Unfortunately I don't remember what was said about it, I'll have to dig it up.
Flags: blocking-firefox2?

Comment 3

12 years ago
I was thinking of the fact that alias records are now opaque (they weren't before Intel). Not the problem here.

On all systems, x86 or PPC, aliases are big-endian. Maybe we need to be byte swapping our alias data before or after we decode it... I haven't looked into the code yet.
Version: unspecified → 1.5.0.x Branch

Updated

12 years ago
Assignee: nobody → joshmoz
Flags: blocking-firefox2? → blocking-firefox2+

Comment 4

12 years ago
Shane - do you have a testcase for reproducing this with Firefox? Otherwise, can you give me the values for "aliasSize" and "dataSize" at this line:

if (aliasSize > (dataSize * 3) / 4) { // be paranoid about having too few data

Updated

12 years ago
Flags: blocking-firefox2+
(Reporter)

Comment 5

12 years ago
I added a debug print:

  PRInt32 aliasSize = GetAliasSizeFromRecord(aliasHeader);
  double maxsize = (dataSize * 3) / 4;
  fprintf(stderr, "aliasSize %d should be <= to %.2f\n", aliasSize, maxsize);

and get output like:

nsLocalFile::SetPersistentDescriptor...
aliasSize 41986 should be <= to 678

If I change the define for GetAliasSizeFromRecord from:

#if !defined(MAC_OS_X_VERSION_10_4) || MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_4
#define GetAliasSizeFromRecord(aliasRecord) aliasRecord.aliasSize
#else
#define GetAliasSizeFromRecord(aliasRecord) GetAliasSizeFromPtr(&aliasRecord)
#endif

to:

#define GetAliasSizeFromRecord(aliasRecord) GetAliasSizeFromPtr(&aliasRecord)

it works correctly.
(Reporter)

Comment 6

12 years ago
perhaps it has something to do with this in our .mozconfig:

ac_add_options --enable-macos-target=10.3

(Assignee)

Comment 7

12 years ago
You shouldn't (mustn't!) set the DT below 10.4 on x86.

Comment 8

12 years ago
Created attachment 228330 [details] [diff] [review]
fix v1.0

The problem is that if you're building on Intel but targeting Mac OS X 10.3 then you use the .aliasSize field instead of the accessor function. Since .aliasSize should work on all PPC systems and the accessor is only really necessary on Intel systems, we can just make the #ifdef for ppc systems and ignore target OS altogether.

Or even better we could do that same OS target test but also require us to be building on PPC systems in order for using .aliasSize to be considered. That is what this patch does.
Attachment #228330 - Flags: review?(mark)

Updated

12 years ago
Flags: blocking1.8.0.6?
Flags: blocking-firefox2?

Updated

12 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Reporter)

Comment 9

12 years ago
ok, verified patch builds and works on PPC 10.3 and x86 10.4
thanks!
(Assignee)

Comment 10

12 years ago
Comment on attachment 228330 [details] [diff] [review]
fix v1.0

This check shouldn't be needed, and it might not be the only part of our code we'd need to apply such a fix to.  The right thing to do is warn or give an error at configure time if someone's targeting x86 with the DT set below 10.4.
Attachment #228330 - Flags: review?(mark) → review-

Comment 11

12 years ago
I agree that we should add a warning about your target OS on Intel, but Shane's setup seems to be far from completely horked even with the bad OS target. Why not take out one major problem with a bad config? Its not like when users run into this problem they realize that their config is wrong - they just get wonder if the bug is in our XPCOM io code, exactly what happened in this bug. They are just as likely to file a bug like this or simply remove the problematic code as they are to actually fix their config.

Comment 12

12 years ago
A bad config warning is not enough because if the user misses it and runs into this problem or something like it, they will just get confused and we'll go through this process all over again. I think we should either take this patch and make a warning, or make it a hard error to configure on Intel with a bad target OS. I prefer the latter.
We won't block the final release of Firefox 2 for this, but would take an approved and baked patch (nominate for approval1.8.1) in the beta2 timeframe in order to prevent frustration from people using our platform.
Flags: blocking-firefox2? → blocking-firefox2-
Target Milestone: --- → Firefox 2 beta2

Comment 14

12 years ago
-> mark for writing a hard error in our configure code
Assignee: joshmoz → mark
Status: ASSIGNED → NEW

Updated

12 years ago
Flags: blocking1.8.0.7?
Product: Firefox → Toolkit
This seems like a core issue to me
Component: Add-ons Manager → XPCOM
Flags: blocking-firefox2-
Product: Toolkit → Core
QA Contact: extension.manager → xpcom
Target Milestone: mozilla1.8.1beta2 → ---
Version: 1.8.0 Branch → 1.8 Branch
(Reporter)

Updated

10 years ago
Blocks: 450553

Comment 16

3 years ago
Expired.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.