19.25 KB, text/plain
excerpt from 06/19 Mac installer packaging automation log: > Linking .xpt files... > [FullCircle] > [browser] > Assertion (0) failed in "xpt_xdr.c" on line 295 > # Error: xpt_link failed. Exiting... Firt occurence: 2001-09-19-08-trunk Reproducibility: 100% since then Consequences: all .xpt files are bundled as is within each .xpi file instead of being linked together into 1. Might increase startup time.
Cathleen confirmed that startup time went up 20% yesterday! None of the xpidl / xptlink code seems to have been touched since Aug. 2000, I will need to dig more to understand why it started failing yesterday. cc'ing engineers who might be familiar with this code, and raising severity to major
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
No change with 06/20 builds. Same error. Cathleen, if this is a MUST for 0.9.2 and corresponding NS release (I would assume so, due to startup time regression), we'll need to get some help tracking this bug down. And btw, don't try to view the attachment using 4.x on Mac, or you'll freeze!
I don't think JJ is the right person to work on this, ccing jband, dmose, & waterson since those are the only names on the xpt_link and xpt_xdr blame list I recognize. As an aside I see xpt_link.c is including xpt_xdr.h which doesn't exist in lxr. Is that an autogenerated file, or a bug?
Priority: -- → P1
Whiteboard: pdt → pdt. 20% startup loss, no fix, no eta. NEED HELP!
This is generally caused by an ill formed xpt file, possible a zero length file. Basically the assert is checking that the buffer is sufficient for the operation and in this case it's not. I'm now the owner of the xpidl area, so this should probably be assigned to me. I'll need help with someone with a Mac, though, as I'm Windows/Linux based. Patrick, could you pitch in?
xpt_hdr.h can be found here -> http://lxr.mozilla.org/seamonkey/source/xpcom/typelib/xpt/public/xpt_xdr.h
Thanks for jumping in, David. I checked today's xpt files, and none are empty. Don't know if this is a coincidence, but the debug log seems to fail after (or during) processing xpinstall.xpt, which is the _last_ xpt file in the browser installer module. Let me konw if you want to look at the problem on the release build mac together, or if you will work on it with Patrick.
So how can those of us without the funky applescript packaging stuff run the xptlink step?
Well, you first need to run pkgcp.pl from xpinstall/packager to split mozilla/ dist/viewer into "installer modules" folders. Because we need to pass arguments to that script, I use AppleScript as follows: --- set kParser to "<srctree>:mozilla:xpinstall:packager:pkgcp.pl" set sourcedir to "FastFreddy:Mozilla Tree:ns:dist" set ModulesFolder to "InternalHD:Desktop Folder:output:" set kMoz_Manifest to "<srctree>:mozilla:xpinstall:packager:packages-mac" tell application "MacPerl" activate with timeout of 10000 seconds -- ±2h45mn. Do Script [kParser, "-s", sourcedir, "-d", ModulesFolder, "-f", kMoz_Manifest, "-o", "mac"] --, "-debug", "4" end timeout end tell --- Then you run xptlink against the result of pkgcp.pl. Here again, perl arguments can be passed using AppleScript: --- set kSourcePath to "FastFreddy:Mozilla Tree:" set xptlink_folder to kSourcePath & "mozilla:xpinstall:packager:mac" set xptLinker to kSourcePath & "mozilla:xpinstall:packager:xptlink.pl" set ModulesFolder to "InternalHD:desktop folder:modules-test" -- *** xpt_link.pl: For each installer module, merges all .xpt files into a single file. tell application "MacPerl" with timeout of 10000 seconds -- ±2h45mn. try -- Call to xptlink.pl Do Script [xptLinker, "-s", xptlink_folder, "-d", ModulesFolder, "-o", "mac", "-debug", "10"] on error errtext number errNum -- my LogMsg("ERROR: MacPerl:xptlink.pl: " & errtext & " (" & errNum & ")", false) end try end timeout end tell --- I was going to work on this with Patrick on the release build mac, since that's where the failure occurs.
One more thing you need to run this is the "xpt_link" MPW tool which gets only built if you have defined "options xptlink 1" in your build prefs file.
fixed by increasing ToolServer memory partition from 7 to 10 MB! Setting it to 15MB to be sure on both trunk and branch build machines. Thanks to Patrick for his clever advice. Please verify against 06/27 verification builds which should include only 1 xpt file per installer module. Cathleen, let us know if this eliminates the startup time increase you reported last week.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Whiteboard: pdt. 20% startup loss, no fix, no eta. NEED HELP!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.