Pls reassign to correct component. I see this on today's commercial beta1 build. 1. Using the 'NetscapeSetup.exe' , install the browser 2. I used a typical install. 3. After the installation, just before the splash screen appears, I get an error message. (Dr. Watson Error ) It says: An application error has occured and an application error log is being generated". netscp6.exe Exception : access violation (0xc0000005), Address :0xc0c27ae1

Clicking on the 'Netscape6' and "Profile Manager' icon does not help.

The only check-ins I see are from racham, unless there was something else on the commercial tree, assigning to him

Information I got from OS GPF: OS GPF says problem is in xpcom.dll NETSCP6 caused an invalid page fault in module XPCOM.DLL at 0177:60c27ae1. Registers: EAX=00000047 CS=0177 EIP=60c27ae1 EFLGS=00010296 EBX=007b8100 SS=017f ESP=0068fc48 EBP=0068fcb4 ECX=006b5658 DS=017f ESI=a000e272 FS=4327 EDX=00000000 ES=017f EDI=007b97e0 GS=0000 Bytes at CS:EIP: 8b 06 3b 05 a0 d7 c2 60 75 2c 8b 46 04 3b 05 a4 Stack dump: 60c13fff 007b8070 007b8100 007a000c 0000003f 0068fcb0 60b975cb 007b9800 60c2b5b8 2efb5009 11d34508 a000daae 8cc0ff24 60c2b5b8 2efb5009 11d34508

netscp6 > foo.txt produces an empty file. netscp6 -console produces stdout directed to dynamic console. stderr directed to dynamic console. FATAL: can't no room for 1 in cursor. debugger says it's an access violation in xpcom.dll.

That "FATAL: can't no room ..." comes from deep in the handling of the typelibs http://lxr.mozilla.org/seamonkey/search?string=CHECK_COUNT. jband, shaver, any clues on what would set this up for failure?

Corrupt typelib? I'm travelling this weekend, so I can't dig deeper right now.

Now suppose the browser.xpt was exactly 32K bytes in size in today's beta1 win32 bits (down from 63,276 bytes yesterday). Yeah, that would seem wrong. As a little experiment, I grabbed the missing ~31,000 bytes from yesterday's browser.xpt, and, presto ... it runs. (Don't try this at home). Remaining question is what happened to browser.xpt today?

I built the commercial tree after my check in. I didn't see any crash like this...

We should probably do some sanity checking to make sure that the file length matches TypeLibHeader.file_length, so we can report a better error message. I'll take a bug on that, but it won't get fixed before the party.

It's possible the build process hiccoughed and didn't create the browser.xpt correctly from the component-xpt files. I'll check the verification log. We can do a repackage today to see if there's an improvement.

shaver, If you file a libxpt bug for better size verification then just assign it to me. I'm hip deep in this stuff anyway. Thanks, John.

Hmm, just as you were entering that, jband, I filed bug #33193 on shaver for more sanity checking on file length, etc. -- so take that one if you want it.

leaf, Are we re-spinning the (beta1) bits...?

yes, it's been done already, i'm closing this bug, as the repackaging didn't fail on xptlink.

fixed on builds this week including 2000-03-30-09