Closed Bug 261734 Opened 20 years ago Closed 20 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: 20 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.

Attachment

General

Creator:
Created:
Updated:
Size: