Closed Bug 36532 Opened 24 years ago Closed 24 years ago

Mozilla hangs on the splash screen when using UNC to launch mozilla.exe

Categories

(SeaMonkey :: General, defect, P2)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: kberk.spamaway, Assigned: dr)

References

Details

(Keywords: relnote, Whiteboard: [nsbeta3-] relnote-user) 

I pulled the tree at 6:00 am PDT today 20 April.  

I clobberd and did an optimize build.  

I deleted the mozregistry.dat file and started mozilla.

When I launch mozilla, it hangs on the splash screen.
adding smoketest keyword.
Keywords: smoketest
I think this bug was fixed by jst backing out a checkin by dcone.  Could you try 
updating that one file and rebuilding?
Target Milestone: --- → M16
I am pulling the tree now.  Should not take too long.  I will do a depend 
build, which is probably an hour and a half.  If anyone else is further along 
in this test, please feel free to close this if it appears fixed and I will 
verify it when I get my build done.

Just noting that the verification build runs on Win2k (does not hang).
Is this a blocker?
Removing smoketest, since jrgm notes that this works for him.
Keywords: smoketest
Ok, here is the scoop.

After the recompile, the problem still existed.  But based on previous 
comments, I assumed this was my problem, so I investigated.

This is the cause:

I have a shortcut on my Windows 2000 Quick Launch Bar that points to mozilla as 
follows:

Target:  \\earthdome\mozilla\dist\WIN32_O.OBJ\bin\mozilla.exe

Start In:  \\earthdome\mozilla\dist\WIN32_O.OBJ\bin

This crashes at the splash screen.



However if I try a different shortcut like this:

Target:  D:\MozBuild\mozilla\dist\WIN32_O.OBJ\bin\mozilla.exe

Start In:  D:\MozBuild\mozilla\dist\WIN32_O.OBJ\bin

Mozilla's profile manager pops up and everything is fine.



If I use the second shortcut, complete the profile, exit mozilla, then try the 
original shortcut; I get the following error:

"Microsoft Visual C++ Runtime Library
"Runtime Error~"
"Program: \\earthdome\mozilla\dist\WIN32_O.OBJ\bin\mozilla.exe

"R6025
-pure virtual function call"



Someone needs to see if this is only on Windows 2000 or if this is a problem 
with all versions of Windows.
Severity: blocker → critical
Keywords: nsbeta2
Summary: Mozilla hangs on the splash screen. → Mozilla hangs on the splash screen when using UNC to launch mozilla.exe
If I start my debug build of mozilla with a share name path

I get an assertions in nsFileSpec:

###!!! ASSERTION: No drive letter part!: 'original[2] == '|'', file x:\seamonkey
\mozilla\xpcom\io\nsFileSpec.cpp, line 622
###!!! Break: at file x:\seamonkey\mozilla\xpcom\io\nsFileSpec.cpp, line 622

It looks like there are various bits of code that are then going to munge this 
path and they do screwy things when the path starts with:

"\\foo\" rather than "x:\"

For me it ends up hanging in event loops.

I'm reassigning this to dougt so that he can address the "c:\" assumption in the 
nsFileSpec (and elsewhere?) code

The stack (for the first time it hits the assertion):

NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x100b7148, const char * 0x100b7134, const char 
* 0x100b7104, int 622) line 191 + 13 bytes
nsFileURL::operator=(const nsFilePath & {...}) line 622 + 37 bytes
nsFileURL::operator=(const nsFileSpec & {...}) line 641 + 21 bytes
nsFileURL::nsFileURL(const nsFileSpec & {...}) line 559
nsChromeRegistry::GetInstallRoot(nsChromeRegistry * const 0x01484a20, 
nsCAutoString & {...}) line 1433
nsChromeRegistry::ConvertChromeURL(nsChromeRegistry * const 0x01484a20, nsIURI * 
0x01485d60) line 379 + 19 bytes
nsChromeProtocolHandler::NewChannel(nsChromeProtocolHandler * const 0x01482fe0, 
nsIURI * 0x01484990, nsIChannel * * 0x0012f6e0) line 685 + 41 bytes
nsIOService::NewChannelFromURI(nsIOService * const 0x00d319b0, nsIURI * 
0x01484990, nsIChannel * * 0x0012f6e0) line 231 + 31 bytes
NS_OpenURI(nsIChannel * * 0x0012f788, nsIURI * 0x01484990, nsIIOService * 
0x00000000, nsILoadGroup * 0x01484d30, nsIInterfaceRequestor * 0x01483954, 
unsigned int 0, unsigned int 0, unsigned int 0) line 103 + 20 bytes
nsDocShell::DoURILoad(nsDocShell * const 0x01483930, nsIURI * 0x01484990, nsIURI 
* 0x00000000, int 0, const char * 0x00000000, nsIInputStream * 0x00000000) line 
2508 + 78 bytes
nsDocShell::InternalLoad(nsDocShell * const 0x01483930, nsIURI * 0x01484990, 
nsIURI * 0x00000000, const char * 0x00000000, nsIInputStream * 0x00000000, 
nsDocShell::loadType loadNormal) line 2281 + 35 bytes
nsDocShell::LoadURI(nsDocShell * const 0x01483930, nsIURI * 0x01484990, 
nsIDocShellLoadInfo * 0x00000000) line 215 + 42 bytes
nsDocShell::LoadURI(nsDocShell * const 0x0148393c, const unsigned short * 
0x01484840) line 1057 + 27 bytes
nsWebShellWindow::Initialize(nsIXULWindow * 0x00000000, nsIAppShell * 
0x00d3b680, nsIURI * 0x01482e20, int 1, int 1, unsigned int 5, int 1, int 1, 
nsWidgetInitData & {...}) line 352 + 45 bytes
nsAppShellService::JustCreateTopWindow(nsAppShellService * const 0x0148a0a0, 
nsIXULWindow * 0x00000000, nsIURI * 0x01482e20, int 1, int 1, unsigned int 
134221822, int 1, int 1, nsIXULWindow * * 0x0012fdd4) line 575 + 52 bytes
nsAppShellService::CreateTopLevelWindow(nsAppShellService * const 0x0148a0a0, 
nsIXULWindow * 0x00000000, nsIURI * 0x01482e20, int 1, int 1, unsigned int 
134221822, int -1, int -1, nsIXULWindow * * 0x0012fdd4) line 493 + 44 bytes
nsProfile::LoadDefaultProfileDir(nsCString & {...}) line 345 + 83 bytes
nsProfile::StartupWithArgs(nsProfile * const 0x00d3d6d0, nsICmdLineService * 
0x0148a3f0) line 271 + 12 bytes
main1(int 1, char * * 0x00c54d40, nsISplashScreen * 0x00000000) line 711 + 41 
bytes
main(int 1, char * * 0x00c54d40) line 968 + 17 bytes
mainCRTStartup() line 338 + 17 bytes
K
Assignee: asadotzler → dougt
my answer is going to be convert the users of nsFileSpec to nsILocalFile.  
nsChromeRegistry -> hyatt.  

http://lxr.mozilla.org/seamonkey/source/rdf/chrome/src/nsChromeRegistry.cpp#1412
Assignee: dougt → hyatt
Putting on [nsbeta2-] radar. Not critical to beta2, but you have until 05/16 to
check in a fix before "[nsbeta2+] bugs only" approved for check in.
Whiteboard: [nsbeta2-]
Status: NEW → ASSIGNED
Target Milestone: M16 → M20
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M20 → Future
This was moved to the future milestone (mass move) when clearly it must be 
fixed before the product goes gold if any distributor wants to sell it 
commercially.

Marking this nsbeta3 so it is not forgotten.
Keywords: nsbeta2 → nsbeta3
Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
Still a problem?  How common is this?
Whiteboard: [nsbeta2-]
nsbeta3+ ->dr
Assignee: dr
Status: ASSIGNED → NEW
Whiteboard: nsbeta3+
Target Milestone: Future → M18
With today's trunk build (2000072708 m18) on win95, launching from a UNC
path (e.g., \\fooserver\path\bar\foo\netscp6.exe), this still crashes if 
there is no mozregistry.dat (which causes a new users50 and profile to be 
created). 

With an already existing mozregistry, users50, profile, etc. it 
does not crash, but AIM and mailnews overlays are not loaded, and the cnn.com
sidebar is displayed in ~24pt fonts (I assume due to some stylesheet 
mishandling, but I don't really know why).
Whiteboard: nsbeta3+ → [nsbeta3+]
Status: NEW → ASSIGNED
The real solution to is to convert the nsChromeRegistry to use nsIFile.
Migrating from the old nsFileSpec at this point would be very risky given the
radically different interfaces. Per trudelle, setting to future and nsbeta3-. In
the meantime, the workaround is to map the network drives (X:\foo rather than
\\bar\foo, for example).
Whiteboard: [nsbeta3+] → [nsbeta3-]
Target Milestone: M18 → Future
Keywords: relnote
I am not sure I like that solution, but to prevent a delay of any sort, I think 
it is acceptable.  We need to make sure this item gets in the releasenotes for 
any shipping products prior to its future fix.  I know network managers will 
need to be aware of this if they intend on a server based deployment.
Yeah, it's sort of a crappy compromise, but it's "good enough" in terms of
having a working product. I won't close the bug, though. This would be a very
nice one to fix given a bit of time, since I think we're the last ones using the
old nsFileSpec...
Depends on: 55115
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-user
see 55115 for relnote
triaging for post-rtm
Severity: critical → major
Priority: P3 → P2
Target Milestone: Future → mozilla0.9
fixed 55115, so this should be fixed...
Keywords: verifyme
reporter: can you verify that this is fixed?
with 2001012109 mozilla build on win2k, I can now start with a UNC path 
(e.g., \\someserver\dir\subdir\bin\mozilla.exe), or with a letter-mapped path 
(e.g., J:\subdir\bin\mozilla.exe). Marking fixed and verified.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.