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

VERIFIED FIXED in mozilla0.9

Status

SeaMonkey
General
P2
major
VERIFIED FIXED
18 years ago
6 years ago

People

(Reporter: Kevin Berkheiser, Assigned: Dan Rosen)

Tracking

({relnote})

Trunk
mozilla0.9
x86
Windows 2000
relnote

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-] relnote-user)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
adding smoketest keyword.
Keywords: smoketest

Comment 2

18 years ago
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
(Reporter)

Comment 3

18 years ago
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.

Comment 4

18 years ago
Just noting that the verification build runs on Win2k (does not hang).
Is this a blocker?

Comment 5

18 years ago
Removing smoketest, since jrgm notes that this works for him.
Keywords: smoketest
(Reporter)

Comment 6

18 years ago
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

Comment 7

18 years ago
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

Comment 8

18 years ago
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

Comment 9

18 years ago
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-]

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M16 → M20

Comment 10

18 years ago
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M20 → Future
(Reporter)

Comment 11

18 years ago
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

Comment 12

18 years ago
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

Comment 13

18 years ago
Still a problem?  How common is this?
Whiteboard: [nsbeta2-]

Comment 14

18 years ago
nsbeta3+ ->dr
Assignee: dr
Status: ASSIGNED → NEW
Whiteboard: nsbeta3+
Target Milestone: Future → M18

Comment 15

18 years ago
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). 

Updated

18 years ago
Whiteboard: nsbeta3+ → [nsbeta3+]

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 16

17 years ago
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

Updated

17 years ago
Keywords: relnote
(Reporter)

Comment 17

17 years ago
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.
(Assignee)

Comment 18

17 years ago
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...
(Assignee)

Updated

17 years ago
Depends on: 55115

Updated

17 years ago
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-user
(Assignee)

Comment 19

17 years ago
see 55115 for relnote
(Assignee)

Comment 20

17 years ago
triaging for post-rtm
Severity: critical → major
Priority: P3 → P2
Target Milestone: Future → mozilla0.9
(Assignee)

Comment 21

17 years ago
fixed 55115, so this should be fixed...
Keywords: verifyme
reporter: can you verify that this is fixed?

Comment 23

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 24

17 years ago
v
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

Updated

9 years ago
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.