38603 - Using Linux installer build, crash after entering URL

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P1)

Description

[David Epstein]

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

Comment 1

[David Epstein]

Changed QA contact to depstein.

Comment 2

[Jon Granrose]

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.

Comment 3

[David Epstein]

one other point to add is that after the Linux installer build is launched, no 
default URL appears. The URL field is blank.

Comment 4

[David Epstein]

I just saw this happen on Mac installer build. 2000-05-09-08-M16. Didn't happen 
on NT.

Comment 5

[David Epstein]

Attachment: Stdlog of mac crash, contains stack crawl (beginning at main)

Comment 6

[leger]

Putting on [dogfood+] radar.  We need this fixed ASAP!!!

Comment 7

[Grace Bush]

add myself and [e-mail] (who is listed for this component) 
This is still occurring on the installed build 2000051208M16.  Mozilla and 
commercial gunzip/tarred versions are ok

Comment 8

[David Epstein]

cc'ing Dan on this.

Comment 9

[Paul Wyskoczka]

Warren, what are the chances of fixing this bug.  It's blocking a number of Mac 
verifications for the XPInstall QA guys. ~ Thanks

Comment 10

[Warren Harris]

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.

Comment 11

[Warren Harris]

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? 

Comment 12

[gordon]

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?

Comment 13

[Grace Bush]

see bug 39749

Comment 14

[gordon]

How is this dogfood+, but nsbeta2-.  Just curious.

Comment 15

[Daniel Veditz [:dveditz]]

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.

Comment 16

[Warren Harris]

I've complained about it too.

Comment 17

[Warren Harris]

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. :-)

Comment 18

[gordon]

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?

Comment 19

[Warren Harris]

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.

Comment 20

[Samir Gehani]

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.

Comment 21

[Jon Granrose]

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.

Comment 22

[Samir Gehani]

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?

Comment 23

[Jon Granrose]

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.

Comment 24

[Daniel Veditz [:dveditz]]

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.

Comment 25

[Cathleen]

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?

Comment 26

[David Epstein]

submitted bug 41131 for the Mac URL crash. 38603 will now solely cover the Linux 
bug.

Comment 27

[Cathleen]

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!  :-)

Comment 28

[David Epstein]

fixed. build 2000-06-06-08-M16.