Closed Bug 190460 Opened 22 years ago Closed 22 years ago

crashes on startup [@ nsZipArchive::ReadInit]

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.3beta

People

(Reporter: dbaron, Assigned: dougt)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

Attachments

(3 files, 1 obsolete file)

renames zlib on windows (includes above patch)
3.51 KB, patch
ssu0262
: review+
darin.moz
: superreview+
asa
: approval1.3b+
Details | Diff | Splinter Review
patch to cleanup old zlib.dll filename from GRE dir
540 bytes, patch
dveditz
: review+
dveditz
: superreview+
asa
: approval1.3b+
Details | Diff | Splinter Review
zlib.dll found first in my PATH.
32.00 KB, application/x-msdownload
Details 
Crashes on startup at nsZipArchive::ReadInit started appearing in talkback with
the 2003-01-22-10 builds.  Here's a stack and the user comments so far:

nsZipArchive::ReadInit   16 
BBID range: 16484919 - 16546898
Min/Max Seconds since last crash: 0 - 1
Min/Max Runtime: 0 - 2
Crash data range: 2003-01-22 to 2003-01-23
Build ID range: 2003012210 to 2003012315
Keyword List : 
Stack Trace: 

         nsZipArchive::ReadInit
[c:/builds/seamonkey/mozilla/modules/libjar/nsZipArchive.cpp  line 604]
         nsJARInputStream::Init
[c:/builds/seamonkey/mozilla/modules/libjar/nsJARInputStream.cpp  line 108]
         nsJAR::GetInputStream 
[c:/builds/seamonkey/mozilla/modules/libjar/nsJAR.cpp  line 346]
         nsJARInputThunk::EnsureJarStream      
[c:/builds/seamonkey/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp  line 95]
         nsJARInputThunk::Read 
[c:/builds/seamonkey/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp  line 119]
         RDFXMLDataSourceImpl::BlockingParse   
[c:/builds/seamonkey/mozilla/rdf/base/src/nsRDFXMLDataSource.cpp  line 583]
         RDFXMLDataSourceImpl::Refresh 
[c:/builds/seamonkey/mozilla/rdf/base/src/nsRDFXMLDataSource.cpp  line 945]
         nsChromeRegistry::InstallProvider     
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp  line 2340]
         nsChromeRegistry::InstallPackage      
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp  line 2765]
         nsChromeRegistry::ProcessNewChromeBuffer      
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp  line 3466]
         nsChromeRegistry::CheckForNewChrome   
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp  line 3340]
         nsChromeRegistry::Init
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp  line 383]
         nsChromeRegistryConstructor   
[c:/builds/seamonkey/mozilla/rdf/chrome/build/nsChromeFactory.cpp  line 68]
         nsGenericFactory::CreateInstance      
[c:/builds/seamonkey/mozilla/xpcom/glue/nsGenericFactory.cpp  line 86]
         nsComponentManagerImpl::CreateInstanceByContractID    
[c:/builds/seamonkey/mozilla/xpcom/components/nsComponentManager.cpp  line 1876]
         nsComponentManagerImpl::GetServiceByContractID
[c:/builds/seamonkey/mozilla/xpcom/components/nsComponentManager.cpp  line 2276]
         nsGetServiceByContractID::operator()  
[c:/builds/seamonkey/mozilla/xpcom/glue/nsComponentManagerUtils.cpp  line 122]
         nsCOMPtr_base::assign_from_helper     
[c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp  line 81]
         nsChromeProtocolHandler::NewURI       
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeProtocolHandler.cpp  line 601]
         nsIOService::NewURI   
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsIOService.cpp  line 406]
         NS_NewURI      [../../../../dist/include/necko\nsNetUtil.h  line 107]
         nsWindowWatcher::URIfromURL   
[c:/builds/seamonkey/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp
 line 1143]
         nsWindowWatcher::OpenWindowJS 
[c:/builds/seamonkey/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp
 line 497]
         nsWindowWatcher::OpenWindow   
[c:/builds/seamonkey/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp
 line 459]
         nsProfile::LoadDefaultProfileDir      
[c:/builds/seamonkey/mozilla/profile/src/nsProfile.cpp  line 537]
         nsProfile::StartupWithArgs    
[c:/builds/seamonkey/mozilla/profile/src/nsProfile.cpp  line 359]
         nsAppShellService::DoProfileStartup   
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp  line 275]
         InitializeProfileService      
[c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp  line 907]
         main1  [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp 
line 1187]
         main   [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp 
line 1639]
         WinMain       
[c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp  line 1660]
         WinMainCRTStartup()
         KERNEL32.dll + 0x2847c (0x77ea847c)
 
        Source File :
c:/builds/seamonkey/mozilla/modules/libjar/nsZipArchive.cpp line : 604
     (16546315) Comments: Just tried to start a new install of Mozilla 1.3
nightly and mozilla goes BOOM!  I had two profiles already created from Mozilla
1.2.1  
     (16518390) Comments: starting nightly build after install
I think I'm seeing this; zlib.inflate_blocks tries to read memory at address
0xFFFFFFF1.
i wonder if this could be related to the "calendar crashing on startup" bug (bug
190326).  odd that this would have started showing up 1/22 and not sooner.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.3beta
that bug does look similar... both are problems directly related to the JAR
handler/decompresser. And both showed up in the last couple of days.

As to this bug only starting on 22nd, that was the date the builds switch to
having the GRE (Gecko Runtime Engine) as a seperate component in the install -
it might well be related to that.
cc'ing GRE folks.  please see previous comment.
are the people who are running into this problem installing into a new dir,
basically *not* ontop of a previous installed build?
I was getting it when installing into a new directory, although I didn't know
about the GRE thing installing into it's own (fixed, damn it) location, so that
will have been overwriting each time (excuding the first time, of course).
> are the people who are running into this problem installing into a
> new dir, basically *not* ontop of a previous installed build?

I've seen it both ways, as an in place upgrade, on top of a previous install, as
well as with a fresh install.
This bug blocks me from using any new Mozilla builds.
Marking BLOCKER...
There wouldn't be a easy workaround for this?
Severity: critical → blocker
I can't reproduce this bug.  Can someone, who can reproduce this problem, try
the .zip file to install mozilla instead of the installer to see if it happens
there as well?
dding crash, regression keywords and making this zt4newcrash.  It's been past 72
hours...but this is a regression that started with 1/22 Trunk builds.  We need
to fix this or identify what checkin from 1/22 caused this crash.

Here's all the recent comments from Talkback data:
(16615627)	Comments: I deleted all folders and profiles and still this build
will not start on Win2K  at least on my computer.  I have even deleted the old
1.2 installation that was in a separate folder.    I had installed this version
into c:\Program
     (16615627)	Comments:  Files\mozilla.org\Mozilla1.3 to keep them separate. 
 Is there a problem with this folder?
     (16615581)	Comments: It just keeps dying and dying and dying...   
     (16615579)	Comments: Died again...  
     (16615578)	Comments: Ok  even cleaning out the old profiles and have no
profiles to start with causes Mozilla to go BOOM!    It will not start on this
computer no matter what I do.  
     (16615528)	Comments: Mozilla will not start with a new install.   I have 2
existing 1.2 profiles and Mozilla (nighlty as of the last week before this
build)  always crashes on start up.       I get the splash screen  and then I
get to fill out this FeedBack agent.  
     (16612915)	Comments: Tried to start up mozilla...it had other plans.
     (16607120)	Comments: Installation of mozilla-win32-installer-sea.exe ended
up with Mozilla splash screen showing and then the program crashing with this error.
     (16604098)	Comments: Mozilla (nightly build 01/25) failed to start after
clean installation
     (16598772)	Comments: Installing nightly build 20030125 to a fresh directory
and fresh user profile  crash occurred during final portion of install.
     (16587750)	Comments: Crashes on startup  before Profile Manager is shown.
     (16587186)	Comments: Fresh install of nightly build 20030124  also deleted
previous Profiles directory  Mozilla nightly build crashed when completing install.
     (16584834)	Comments: Startup
     (16572576)	Comments: Crashed while Mozilla was starting up during the
installation process.
     (16569652)	URL: http://www.hacksrus.com/~ginda/chatzilla/
     (16568973)	Comments: crashes when I open try and run mozilla.exe
     (16567382)	Comments: Start up of new installation - GRE installed to
different drive than specified in install process
     (16565811)	URL: http://www.hacksrus.com/~ginda/chatzilla/
     (16565801)	URL: http://www.hacksrus.com/~ginda/chatzilla/
     (16563683)	Comments: Ran the network install and during program startup  it
crashed.
     (16546315)	Comments: Just tried to start a new install of Mozilla 1.3
nightly and mozilla goes BOOM!  I had two profiles already created from Mozilla
1.2.1  
     (16518390)	Comments: starting nightly build after install
Keywords: crash, regression, zt4newcrash
my changes on the 21st could not have caused this.  i also don't see any libjar
changes during that time period.
I'm able to cause a crash, but not this exact one.  It's the same stack trace as
bug 190459.  That bug will be fixed when bug 190144 is fixed.  I have a feeling
that this bug will also go away when bug 190144 is fixed.
-> ssu
Assignee: darin → ssu
Status: ASSIGNED → NEW
bug 190144 has been fixed.  closing this bug as fixed too.  if people are still
running into this bug, please reopen.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Doh!
2002012804 still crashes on startup!
Talkback ID:TB16673402E
Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
dbradley says that talkback ID does correspond to nsZipArchive::ReadInit.
BTW, I just downloaded the 2003012804 and am actually using it to post this, so
this DOES NOT affect the zip-archives.
looking again...
Status: REOPENED → ASSIGNED
Here's Markus' incident:

Incident ID 16673402
Stack Signature 	nsZipArchive::ReadInit a54014d3
Email Address 	
Product ID 	MozillaTrunk
Build ID 	2003012804
Trigger Time 	2003-01-28 07:49:18
Platform 	Win32
Operating System 	Windows 98 4.10 build 67766222
Module 	JAR50.DLL
URL visited 	
User Comments 	Crashed on startup.
Trigger Reason 	Access violation
Source File Name 	c:/builds/seamonkey/mozilla/modules/libjar/nsZipArchive.cpp
Trigger Line No. 	604
Stack Trace 	
nsZipArchive::ReadInit
[c:/builds/seamonkey/mozilla/modules/libjar/nsZipArchive.cpp, line 604]
nsJARInputStream::Init
[c:/builds/seamonkey/mozilla/modules/libjar/nsJARInputStream.cpp, line 108]
nsJAR::GetInputStream [c:/builds/seamonkey/mozilla/modules/libjar/nsJAR.cpp,
line 346]
nsJARInputThunk::EnsureJarStream
[c:/builds/seamonkey/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 95]
nsJARInputThunk::Read
[c:/builds/seamonkey/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 119]
RDFXMLDataSourceImpl::BlockingParse
[c:/builds/seamonkey/mozilla/rdf/base/src/nsRDFXMLDataSource.cpp, line 583]
RDFXMLDataSourceImpl::Refresh
[c:/builds/seamonkey/mozilla/rdf/base/src/nsRDFXMLDataSource.cpp, line 945]
nsChromeRegistry::InstallProvider
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp, line 2340]
nsChromeRegistry::InstallPackage
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp, line 2765]
nsChromeRegistry::ProcessNewChromeBuffer
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp, line 3466]
nsChromeRegistry::CheckForNewChrome
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp, line 3340]
nsChromeRegistry::Init
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp, line 383]
nsChromeRegistryConstructor
[c:/builds/seamonkey/mozilla/rdf/chrome/build/nsChromeFactory.cpp, line 68]
nsGenericFactory::CreateInstance
[c:/builds/seamonkey/mozilla/xpcom/glue/nsGenericFactory.cpp, line 86]
nsComponentManagerImpl::CreateInstanceByContractID
[c:/builds/seamonkey/mozilla/xpcom/components/nsComponentManager.cpp, line 1876]
nsComponentManagerImpl::GetServiceByContractID
[c:/builds/seamonkey/mozilla/xpcom/components/nsComponentManager.cpp, line 2276]
nsGetServiceByContractID::operator()
[c:/builds/seamonkey/mozilla/xpcom/glue/nsComponentManagerUtils.cpp, line 122]
nsCOMPtr_base::assign_from_helper
[c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp, line 81]
nsChromeProtocolHandler::NewURI
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeProtocolHandler.cpp, line 601]
nsIOService::NewURI
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsIOService.cpp, line 406]
NS_NewURI [../../../../dist/include/necko\nsNetUtil.h, line 107]
nsWindowWatcher::URIfromURL
[c:/builds/seamonkey/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp,
line 1143]
nsWindowWatcher::OpenWindowJS
[c:/builds/seamonkey/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp,
line 497]
nsWindowWatcher::OpenWindow
[c:/builds/seamonkey/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp,
line 459]
nsProfile::LoadDefaultProfileDir
[c:/builds/seamonkey/mozilla/profile/src/nsProfile.cpp, line 537]
nsProfile::StartupWithArgs
[c:/builds/seamonkey/mozilla/profile/src/nsProfile.cpp, line 359]
nsAppShellService::DoProfileStartup
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 275]
InitializeProfileService
[c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 907]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1187]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1639]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1660]
WinMainCRTStartup()
KERNEL32.DLL + 0x1b537 (0xbff8b537)
KERNEL32.DLL + 0x1b3e9 (0xbff8b3e9)
KERNEL32.DLL + 0x19dac (0xbff89dac) 
Here's something interesting that I found.  This crash has a very similar stack
trace to this bug, but it was reported back in 12/30/2002.  It looks like this
bug might have been around for a while, but with the recent GRE landing, it's
now happening more often.

Gecko1.0      Netscp.exe 7.0.0.0
 Win32 (2002082310)
Trigger Time: 12/30/2002 18:44:45

Trigger Type:   Program Crash
Trigger Reason:  Access violation
Thread ID: 
Call Stack:    (Signature = nsZipArchive::ReadInit a8a06bb3)
    	nsZipArchive::ReadInit 
[d:\builds\seamonkey\mozilla\modules\libjar\nsZipArchive.cpp, line 604]
    	nsJARInputStream::Init 
[d:\builds\seamonkey\mozilla\modules\libjar\nsJARInputStream.cpp, line 108]
    	nsJAR::GetInputStream 
[d:\builds\seamonkey\mozilla\modules\libjar\nsJAR.cpp, line 346]
    	nsJARChannel::GetInputStream 
[d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 681]
    	nsJARChannel::OpenJARElement 
[d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 238]
    	nsJARChannel::EnsureJARFileAvailable 
[d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 317]
    	nsJARChannel::Open 
[d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 249]
    	NS_OpenURI 	[..\..\..\..\dist/include/necko\nsNetUtil.h, line 204]
    	CSSLoaderImpl::LoadAgentSheet 
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1597]
    	nsChromeRegistry::LoadStyleSheetWithURL 
[d:\builds\seamonkey\mozilla\rdf\chrome\src\nsChromeRegistry.cpp, line 2890]
    	nsChromeRegistry::LoadStyleSheet 
[d:\builds\seamonkey\mozilla\rdf\chrome\src\nsChromeRegistry.cpp, line 2875]
    	nsChromeRegistry::LoadProfileDataSource 
[d:\builds\seamonkey\mozilla\rdf\chrome\src\nsChromeRegistry.cpp, line 2952]
    	nsChromeRegistry::ConvertChromeURL 
[d:\builds\seamonkey\mozilla\rdf\chrome\src\nsChromeRegistry.cpp, line 533]
    	nsChromeProtocolHandler::NewChannel 
[d:\builds\seamonkey\mozilla\rdf\chrome\src\nsChromeProtocolHandler.cpp, line 627]
    	nsIOService::NewChannelFromURI 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsIOService.cpp, line 779]
    	NS_NewChannel 	[..\..\..\dist/include/necko\nsNetUtil.h, line 162]
    	NS_OpenURI 	[..\..\..\dist/include/necko\nsNetUtil.h, line 200]
    	nsStringBundle::LoadProperties 
[d:\builds\seamonkey\mozilla\intl\strres\src\nsStringBundle.cpp, line 206]
    	nsStringBundle::GetStringFromName 
[d:\builds\seamonkey\mozilla\intl\strres\src\nsStringBundle.cpp, line 390]
    	nsPrefBranch::GetDefaultFromPropertiesFile 
[d:\builds\seamonkey\mozilla\modules\libpref\src\nsPrefBranch.cpp, line 851]
    	nsPrefBranch::GetComplexValue 
[d:\builds\seamonkey\mozilla\modules\libpref\src\nsPrefBranch.cpp, line 296]
    	nsHttpHandler::PrefsChanged 
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpHandler.cpp, line 1312]
    	nsHttpHandler::Init 
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpHandler.cpp, line 226]
    	nsHttpHandler::Create 
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpHandler.cpp, line 181]
    	nsGenericFactory::CreateInstance 
[d:\builds\seamonkey\mozilla\xpcom\glue\nsGenericFactory.cpp, line 78]
    	nsComponentManagerImpl::CreateInstance 
[d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 1731]
    	nsComponentManagerImpl::GetService 
[d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 1905]
    	nsGetServiceByCID::operator() 
[d:\builds\seamonkey\mozilla\xpcom\glue\nsComponentManagerUtils.cpp, line 102]
    	nsCOMPtr_base::assign_from_helper 
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 81]
    	nsPluginHostImpl::UserAgent 
[d:\builds\seamonkey\mozilla\modules\plugin\base\src\nsPluginHostImpl.cpp, line
2900]
    	jpins32.dll + 0x9613 (0x01f59613) 	 
    	nsPluginHostImpl::GetPluginFactory 
[d:\builds\seamonkey\mozilla\modules\plugin\base\src\nsPluginHostImpl.cpp, line
4665]
    	nsJVMManager::StartupJVM 
[d:\builds\seamonkey\mozilla\modules\oji\src\nsJVMManager.cpp, line 671]
    	nsJVMManager::MaybeStartupLiveConnect 
[d:\builds\seamonkey\mozilla\modules\oji\src\nsJVMManager.cpp, line 902]
    	nsJVMManager::StartupLiveConnect 
[d:\builds\seamonkey\mozilla\modules\oji\src\nsJVMManager.h, line 144]
    	nsJSEnvironment::Init 
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1685]
    	NS_CreateScriptContext 
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1727]
    	nsDOMSOFactory::NewScriptContext 
[d:\builds\seamonkey\mozilla\dom\src\build\nsDOMFactory.cpp, line 156]
    	nsDocShell::EnsureScriptEnvironment 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 6184]
    	nsWebShell::GetInterface 
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 296]
    	nsGetInterface::operator() 
[d:\builds\seamonkey\mozilla\xpcom\glue\nsIInterfaceRequestorUtils.cpp, line 55]
    	nsCOMPtr_base::assign_from_helper 
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 81]
    	nsDocShell::InternalLoad 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 4471]
    	nsDocShell::LoadURI 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 668]
    	nsDocShell::LoadURI 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2395]
    	nsWebShellWindow::Initialize 
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 344]
    	nsAppShellService::JustCreateTopWindow 
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 722]
    	nsAppShellService::CreateHiddenWindow 
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 425]
    	main1 	[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1447]
    	main 	[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1839]
    	WinMain 	[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line
1857]
    	WinMainCRTStartup() 	 
    	kernel32.dll + 0x214c7 (0x77e814c7) 	 
Registers:
EAX:	00000000 	EBX:	0012ead8 	ECX:	00ee3508 	EDX:	00ed1008
ESI:	0012dad8 	EDI:	2dda12f7 	ESP:	0012fff8 	EBP:	00000000
EIP:	00000000 	cf PF af ZF sf of IF df nt RF vm   IOPL: 0
CS:	001b	DS:	0023	SS:	0023	ES:	0023	FS:	0038	GS:	0000
Command Line:  "C:\Program Files\Netscape\Netscape\Netscp.exe"
For those people running into this crash, can you check to see if there's
another copy of zlib.dll in your path (or anywhere on the system), namely in one
of the following dirs:
 [windir] - ie c:\windows
 [winsysdir] - ie c:\windows\system32 or c:\windows\system

that last stack trace also pre-dates my async-io patch (bug 176919).

i tried running valgrind (linux) to see if there aren't any buffer overruns that
could explain this, but i didn't hit anything interesting.
Forgot to mention that if a zlib.dll is found that is not in either the GRE or
Mozilla dirs, rename it out of the way and try mozilla again.  See if that works.
Very interesting comment, Sean - I have 12 zlib.dll files, and although none are
in the Windows directories, at least one is in my normal path (thanks to 'which'
and Cygwin there!).

And, as you suggested, running Mozilla (2003012804) does work if there are no
zlib.dll files in the path (yay!).

This does, of course, beg the question of why Mozilla's ending up looking in the
path for the DLL, before trying the GRE install location.
the answer to that is easy... I suck. :-/

patch coming up shortly.
Assignee: ssu → dougt
Status: ASSIGNED → NEW

    
    

    
  
I don't see how it won't work... what your patch did was put the GRE path before
the base system path. I had many zlib.dll files, but none were in the Winnt or
system32 directories - so the patch will (at least in theory) work for me.

It's a more general problem the search path - all the DLLs in /components work,
don't they? How does Mozilla tell Windows where they are? Can you not use that
for the GRE stuff too? (ok, so this patch may not fix the big picture, but it
would at least help the majority of people, IMHO)

    
    

    
  
James, that still won't fix the problem because zlib.dll is not explicitly
loaded.  It's implicitly loaded by the OS, in which case it will default to
using it's own search rule.  I believe that the default search rule is this:
 1) current working dir (which might not be GRE or mozilla)
 2) windows/windows system directories
 3) standard environment search path

I have heard that there are apps that install zlib.dll into the windows
dirctory, so we'll still be crashing in that case.

If we're going to fix this, we should do it for all cases.  There are a couple
of ways that we can probably fix this (dougt is already investigating):
 * rename mozilla's copy of zlib.dll to something more unique (nsZlib.dll or
myZlib.dll perhaps :))?
 * statically link in zlib_s.lib with xpcom.dll

We'll need to make sure that there aren't any other .dlls that are in this
similar situation.

    
    

    
  
I know the patch doesn't address the general problem, but that's what I was
saying - how does Mozilla make sure it's libraries are loaded from /components
anyway? Does it even bother to care? If it doesn't care, it's a hell of a big
problem just waiting to happen...

But, I was trying to make another point - if you put this patch in now, it'll
fix this for the majority of people (I believe), and give you time to work on a
real solution without loads of people whining/filing dup bugs about it.

    
    

    
  
FYI: The installer had the same problem with a zlib.dll, see bug 167515
(changed DLL search order in XP SP1)

    
    

    
  
okay.  why the heck do we name the library zlib?  on linux it is something else.
 How about just continue that on windows?


Flags: blocking1.3b?

    
    

    
  


  

        Attachment #112932 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 112944 [details] [diff] [review]
renames zlib on windows (includes above patch)

sounds like a good plan to me.	mozzlib might have been better, but whatever.

r/sr=darin

        Attachment #112944 -
        Flags: superreview+

    
    

    
  
Comment on attachment 112944 [details] [diff] [review]
renames zlib on windows (includes above patch)

looks good to me too.
r=ssu

        Attachment #112944 -
        Flags: review+

    
    

    
  


  
dougt, can you check this in along with your patch (after I get the r=/sr/a=)? 
we should cleanup the old zlib filename from the GRE dir.  We're already
cleaning it up from the Mozilla dir, so no need to do anything there.

    
  

        Attachment #112950 -
        Flags: superreview?(dveditz)

        Attachment #112950 -
        Flags: review?(dougt)

    
    

    
  
  The reason that we use zlib.dll on windows is because, per bug 86323,
embeddors and third-party plugins wanted to use the standard zlib library and
our (previously) non-standard one was causing problems.  If loading a "system"
version of zlib.dll is causing a crash, it sounds like the version being loaded
has a non-standard signature.  I'm not convinced that we're doing anything wrong
here by using the standard library name with the standard stdcall signature.

If you rename the library, you're going to force embeddors who use zlib in their
own applications to load 2 copies of the symbols to use the same library
(assuming that the app doesn't try to load both sets of symbols into the same
address space).  In a static embedding build, it may not work at all (bug
119934).  <Insert standard complaint about 3rd party libs in the tree here.>

FWIW, it's named something else on linux due to bug 57247.


    
    

    
  
suu - sure.

seawood - 

I asked James to send me the library exports of his zlib copy (the one that
caused the crash).  However, looking at talkback data, this isn't an uncommon
setup where an incompatible zlib is somewhere in the users's path.  

James, if you don't mind too much, can you just attach the zlib library to this bug?



    
    

    
  


  
Just one of the 12 zlib.dlls on my system, of which there are 9 different ones.


(Doug - for a rather complicated set of reasons, I get bugmail instantly, but
only check twpol@aol.com once a day at most.)

    
    

    
  
Another tack could be to put zlib.dll back in the mozilla.exe directory. Then we
either live with the duplication, or remove it from the GRE and instruct
embeddors that this is something they have to supply. This might be the
direction bug 86323 was trying to nudge us toward in the first place.

Could we have Mozilla.exe explicitly LoadLibrary([GRE_PATH]"\\zlib.dll") before
initializing xpcom? Once it's loaded everyone will use the same one, but that
only helps Mozilla and other embedding apps will have the same basic problem.

    
    

    
  
wow.  the ordinals are totally different between the two libs!  This is exactly
why we are crashing.  

    
    

    
  
I have had this crash on winXP with recent nightlies. The 'details' from
talkback gave no clue as to the cause (no hint of a zlib.dll problem - the only
pointer I had was to jar50.dll) - my concerns were triggered with the GRE
install (and the lack of availability to specify which drive / directory GRE
components installed themselves)

It took a while to track down the zlib.dll cause for this - it is not just
Windows 98 crash I was hit on XP - and some crashes may not be clearly zlib
related (mine included talkback TB16718761 which didn't make any connection with
zlib or nsZipArchive) really pleased to find the workaround in comment 21.

    
    

    
  
this is the top crash on the trunk right now. setting to blocking 1.3b+
Flags: blocking1.3b? → blocking1.3b+

    
    

    
  
i checked in patch 112932 (accidently).  This should help out for all cases but
putting zlib in the window.  

    
    

    
  
Comment on attachment 112944 [details] [diff] [review]
renames zlib on windows (includes above patch)

a=asa (on behalf of drivers) for checkin to 1.3beta.

        Attachment #112944 -
        Flags: approval1.3b+

    
    

    
  
Comment on attachment 112950 [details] [diff] [review]
patch to cleanup old zlib.dll filename from GRE dir

I don't know that renaming is the way to go (the previous patch), but if we do
go that way we need to do this. r+sr=dveditz

        Attachment #112950 -
        Flags: superreview?(dveditz)

        Attachment #112950 -
        Flags: superreview+

        Attachment #112950 -
        Flags: review?(dougt)

        Attachment #112950 -
        Flags: review+

    
  

        Attachment #112950 -
        Flags: approval1.3b?

    
    

    
  
Comment on attachment 112950 [details] [diff] [review]
patch to cleanup old zlib.dll filename from GRE dir

a=asa (on behalf of drivers) for checkin to 1.3beta.

        Attachment #112950 -
        Flags: approval1.3b? → approval1.3b+

    
    

    
  
everything has been checked in.  please verify.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED

    
  
OS: Windows 98 → All

    
    

    
  
According to Talkback data...no crashes since 1/29 MozillaTrunk builds.  Marking
verified. 
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsZipArchive::ReadInit]

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: