95.13 KB, text/plain
Linux only. build 2000-05-08-08. 1. Download Linux installer from build folder. 2. Run Linux installer stub and install to another folder ("may08-inst2" folder). There is core crash at the end. see bug 36781. 3. Launch Mozilla. 4. Enter a URL and press Enter. Result: Browser closes. 5. Try relaunching. Result: It doesn't relaunch. Notes: I also extracted/unzipped the same build from the build folder. Copied to a folder called "may08-unzip". Then, did a diff between the contents of "package" folder inside of "may08-unzip" and "may08-inst2". There were several files missing in "may08-inst2" that were in "package". After copying these files to "may08-inst2" (incl component.reg which had differences), I was able to relaunch Mozilla, but after entering a URL, the browser still closed. Note that the Mozilla inside "package" launched and returned URLs fine. Here is the diff listing: /u/depstein/builds/M16/may08-unzip >diff package/ ../may08-inst2/ Only in package/: TestGtkEmbed Only in package/: bloaturls.txt Common subdirectories: package/chrome and ../may08-inst2/chrome Only in ../may08-inst2/: component-1.reg Binary files package/component.reg and ../may08-inst2/component.reg differ Common subdirectories: package/components and ../may08-inst2/components Common subdirectories: package/defaults and ../may08-inst2/defaults Common subdirectories: package/icons and ../may08-inst2/icons Only in package/: libcmt.so Only in package/: libgtkembedmoz.so Only in package/: libgtkxtbin.so Only in package/: libjpeg.so Only in package/: libprotocol.so Only in package/: libzlib.so Only in package/: mozilla-config Only in package/: mozilla-installer-bin Common subdirectories: package/plugins and ../may08-inst2/plugins Only in ../may08-inst2/: registry Common subdirectories: package/res and ../may08-inst2/res Common subdirectories: package/searchplugins and ../may08-inst2/searchplugins Only in package/: timebombgen Only in package/: xpidl Only in package/: xpt_dump Only in package/: xpt_link
Changed QA contact to depstein.
Keywords: crash, pp
QA Contact: granrose → depstein
don't look at me. I have no idea what files have been added/deleted, and can't just update the packages file to include everything since I don't know what's supposed to be in the released product. I'm assuming it's one of the lib* files, but don't see any recent changes to the makefiles generating those libraries to indicate a new library or new name for an old library. Reassigning to warren on the off chance that he might know something about this since I know he added/removed some files the other day. Don't know if he is causing this particular problem though.
Assignee: granrose → warren
Target Milestone: --- → M16
one other point to add is that after the Linux installer build is launched, no default URL appears. The URL field is blank.
I just saw this happen on Mac installer build. 2000-05-09-08-M16. Didn't happen on NT.
Summary: Using Linux installer build, crash after entering URL → Using Linux (or Mac) installer build, crash after entering URL
Putting on [dogfood+] radar. We need this fixed ASAP!!!
add myself and email@example.com (who is listed for this component) This is still occurring on the installed build 2000051208M16. Mozilla and commercial gunzip/tarred versions are ok
cc'ing Dan on this.
Warren, what are the chances of fixing this bug. It's blocking a number of Mac verifications for the XPInstall QA guys. ~ Thanks
I'm not going to be able to get to this until sometime next week at the earliest. I don't have access to a mac or linux box at home. Can someone do an install, but then swap the release version of mozilla.exe with a debug version and give me a stack trace of the crash? That will help me figure out what might be missing.
I can't tell anything from that stack crawl. I think we're going to have to catch it in the act. Isn't there a mac person that can look at this?
I just tried to install MozillaInstaller-M16.sea.bin, and it simply quit after pressing the install button. It didn't create any files on my disk. How recent is this behavour?
see bug 39749
How is this dogfood+, but nsbeta2-. Just curious.
For whatever reason the PDT appear allergic to having two plusses, and when they change a bug to dogfood+ they move it to nsbeta2- Everyone else thinks this is counter-intuitive.
I've complained about it too.
Gordon and I determined that this is related to missing xpt files in the commercial installed bits. He copied over the ones from his debug build into the install directory and everything worked. (Note that this is not related to the change I made for necko a couple of weeks ago. :-)
Actually, the xpt files were from the posted mozilla build from the same day, not from my debug build. Is there a way for us to build the installer so we can verify changes to the package list?
I just looked at the commercial vs. mozilla installer files, and the commercial seems to be a delta on the mozilla one. So at this point, I have no idea why the commercial build process isn't picking up the mozilla xpt files. Handing this back to Cathleen.
Assignee: warren → cathleen
To address warren's request: you can build the installer on Linux by running the deliver.pl script. > cd mozilla/xpinstall/packager/unix > perl deliver.pl You will find the installer blob delivered to mozilla/installer/sea which contains the .xpis and everything. Run the installer as you normally would.
all the .xpt files are linked into a single .xpt file as part of the verification build process for better performance using dp's xptlink program. there should just be one .xpt file for each component listed in the the packages-win/mac/unix file.
Jon, Actually xptlink is called after pkgcp.pl: http://lxr.mozilla.org/seamonkey/source/xpinstall/packager/unix/deliver.pl#119 So all the individual .xpt's (subcomponent granular) should be in the packages manifests, right?
right. the individual .xpt files are copied to a staging area, then xptlink merges them all into a single xpt file, then pkgcp (or in the case of linux, deliver.pl) is run over the staging area to create the .xpi files. the linux automation is checked into ns/build/unix/verification/seamonkey-build which is called by seamonkey-spawn if anyone's curious about the exact commands, sequence, etc.
Wait, wait! I thought jband put a lot of work into trying to determine which xpt files we actually needed at startup and combining just those, and then leaving the rest of the .xpt files individually or in smallish clumps. We're taking quite a startup performance hit if we have only one .xpt per installed component, not to mention wasted memory storing typelib information for classes used only rarely.
who besides jband (who's on sabbatical) has the list for the subset of xpt files we need for startup? Can we get the missing list xpt files from gordan and get commercial install builds fixed first then worry about getting the thing fine tuned for startup?
submitted bug 41131 for the Mac URL crash. 38603 will now solely cover the Linux bug.
Summary: Using Linux (or Mac) installer build, crash after entering URL → Using Linux installer build, crash after entering URL
Dan and I spent a gread deal of time figured out the missing files and updated packages-unix. Hope tomorrow's build will be much better! :-)
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
fixed. build 2000-06-06-08-M16.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.