Closed Bug 261734 Opened 16 years ago Closed 16 years ago

installer crashes given any commandline arguments

Categories

(Firefox :: Installer, defect)

1.0 Branch
x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: ajschult784, Assigned: ajschult784)

References

Details

(Keywords: crash, fixed-aviary1.0)

Attachments

(1 file, 1 obsolete file)

if the installer is given any commandline arguments, it attempts to parse them
(ParseArgs) before calling ParseConfig, which sets up gCtx and loads the
resources.  ParseArgs tries to use gCtx if any of the commandline arguments are
actually valid and the installer crashes.
Flags: blocking-aviary1.0?
betting that this might be an easy fix.  if a patch appears renominate.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Attached patch patch (obsolete) — Splinter Review
parse config before args
Assignee: bryner → ajschult
Status: NEW → ASSIGNED
Attachment #160427 - Flags: review?(bryner)
Flags: blocking-aviary1.0- → blocking-aviary1.0?
Comment on attachment 160427 [details] [diff] [review]
patch

r=dveditz

How did this end up in the opposite order from the original version in
mozilla/xpinstall/wizard?
Attachment #160427 - Flags: review?(bryner) → review+
Comment on attachment 160427 [details] [diff] [review]
patch

would be good to get bryner to look anyway just in case there was a reason for
changing this in the first place. Plus I realized I probably don't have r=
authority here anyway.
Attachment #160427 - Flags: superreview?(bryner)
Comment on attachment 160427 [details] [diff] [review]
patch

I think the reason I reordered this is because gtk_init() needs to be called
before ParseConfig (because ParseConfig can call ErrorHandler which throws a
gtk dialog).  I was giving ParseArgs a crack at the arguments before gtk, but
since I don't think there's any conflict there, it would probably be best to do
it in this order:

gtk_init
ParseConfig
ParseArgs

make sense?
Attachment #160427 - Flags: superreview?(bryner) → superreview-
> gtk_init
> ParseConfig
> ParseArgs
>
> make sense?

this breaks the idea that silent mode shouldn't try to open the display.

in Seamonkey, I made the Errorhandler check if the display was open and (if not)
to print the message to the console
http://lxr.mozilla.org/mozilla/source/xpinstall/wizard/unix/src2/nsXInstaller.cpp#434
So, we could move gtk_init back to RunWizard, I guess, and bring over the fix to
print errors to the console if the display isn't [yet] open.
Attached patch patchSplinter Review
something like this
Attachment #160599 - Flags: superreview?(dveditz)
Attachment #160599 - Flags: review?(ajschult)
Comment on attachment 160599 [details] [diff] [review]
patch

looks good
Attachment #160599 - Flags: review?(ajschult) → review+
ok, lets take this if we can get it in quick.
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Comment on attachment 160599 [details] [diff] [review]
patch

sr=dveditz
Attachment #160599 - Flags: superreview?(dveditz) → superreview+
Attachment #160427 - Attachment is obsolete: true
Attachment #160599 - Flags: approval-aviary?
Comment on attachment 160599 [details] [diff] [review]
patch

i'm going to interpret comment 10 as approval.
Attachment #160599 - Flags: approval-aviary? → approval-aviary+
checked in
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
*** Bug 264191 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → installer
You need to log in before you can comment on or make changes to this bug.