107181 - Mozilla won't start up when drive name is "/" or contains non-ASCII characters

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[cristiana]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.5+)
Gecko/20011026
BuildID:    2001102605

I changed the name of my hard drive from an english name, to a japanese one,
then when i started mozilla it instantly crashes.

Reproducible: Always
Steps to Reproduce:
1. change hard drive name from english to japanese (e.g from 'computer' to '??
????')
2.start mozilla
3.watch it crash

Actual Results:  mozilla doesnt startup, instantly crashes

Expected Results:  start up without crashing

Comment 1

[Greg K.]

Reporter, can you attach a CrashReporter report?

Comment 2

[cristiana]

Attachment: CrashReporter log

Comment 3

[Roy Yokoyama]

teruko: I am not very familiar with Mac, can you test on Windows as well?
I think here is what you do:
1) install moz to a windows folder (say c:\moz\20011029)
2) run moz at least once
3) change the folder name to a Japanese folder name ( c:\moz\<japanese goes here> ) 
4) run moz to see what happens.
5) if crash, then please change the platform to ALL

However, my real question is 
Is above test case valid?  Is this common on Mac OS?
-> nhotta

Comment 4

[nhottanscp]

ylong, could you try this and confirm if reproducible?

Comment 5

[Yuying Long]

I couldn't reproduce it on Mac OS X(10.1) and Mac OS 9, also WinME-Ja neither.

Reporter: what version of your Mac OS X?

Comment 6

[cristiana]

i am using 10.1

Comment 7

[Greg K.]

Someone please take a look at the reporter's attached CrashReporter log.

Comment 8

[nhottanscp]

Confirm (the log is attached).

Thread 0:
 #0   0x00606058 in nsComponentManagerImpl::FreeServices(void)
 #1   0xbffff71c in 0xbffff71c
 #2   0x0063ab34 in NS_ShutdownXPCOM
 #3   0x00545698 in main

That is mozilla code. Others look like inside OS.

Comment 9

[nhottanscp]

I can reproduce this with 6.2.

I have no idea about the crash in xpcom, cc to dougt, alecf.

Comment 10

[Yuying Long]

OK, here is the result on my machine:
If I set Mac OS X region to Japanese with Japanese hard drive name, I don't see
the crash on N6.2 nor 10-29 trunk build.

If I set OS region to English with Japanese hard drive name, I will see a crash
on 10-29 trunk build but still not crash on N6.2 build.

Comment 11

[Alec Flett]

that's a really strange crash.. was this on a debug build? no assertions or
anything?

Comment 12

[Doug Turner (:dougt)]

Can someone show which line is failing in FreeService()?

Is this reproducible with todays build?

Comment 13

[Simon Fraser [no longer active]]

Conrad has similar bugs, I think.

Comment 14

[nhottanscp]

I am using 6.2 release build. I found the similar crash happens without having
Japanese disk name. After launching the app, immediately quit by applekey+'Q',
then I see the crash one out of 5.

Comment 15

[nhottanscp]

Attachment: Crash report, quitting immediatly after launch, NS6.2 (no JA disk name).

Comment 16

[Conrad Carlen (not reading bugmail)]

See bug 87831.

Comment 17

[nhottanscp]

>If I set Mac OS X region to Japanese with Japanese hard drive name, I don't see
>the crash on N6.2 nor 10-29 trunk build.
IQA, please make sure above is true.

Comment 18

[nhottanscp]

Frank told me that similar problem has been fixed for non ASCII path name by Conrad.
Conrad, have you checked in the fix to the trunk? Do you know the bug number?

Comment 19

[nhottanscp]

Okay, I see you alredy mentioned it bug 87831.
I cannot reproduce the crash using 11/1 commercial trunk, so that might had
fixed the problem.

Comment 20

[Yuying Long]

I checked it on another Mac OS X machine here with Japanese hard drive name:

Set region to Japanese:
No crash on N6.2(0.9.4) build.
Hang on 11-01 trunk build.

Set region to US:
Crashes on both N6.2 and 11-01 trunk build.

Comment 21

[nhottanscp]

Right, it still crashes unless I have Japanese UI as default.

Comment 22

[nhottanscp]

Conrad, could you take a look at this, or point me which code to look at (e.g.
where in the profile mgr hard disk name is manipulated)?

Comment 23

[Conrad Carlen (not reading bugmail)]

It doesn't have to do with profile mgr. It's anything which calls
nsIFile::GetPath(). The component mgr is the 1st victim. Read the comments
starting about 1/2 way down on bug 87831.

Comment 24

[nhottanscp]

Because the crash does not happen when the primary language is set to Japanese,
I thought it's something to do with charset conversion. So I put printf for
nsPlatformCharset, also for nsLocalFile::GetPath.

But didn't get to nsPlatformCharset. It looks like crashing very early in the
start up. Below is part of the console log, after two assersions of
"NS_InitXPCOM failed", followed by the thread assertion.

nsLocalFile::GetPath
nsLocalFile::GetPath
###!!! ASSERTION: NS_InitXPCOM failed: 'NS_SUCCEEDED(rv)', file nsAppRunner.cpp,
line 1604
###!!! ASSERTION: NS_InitXPCOM failed: 'NS_SUCCEEDED(rv)', file nsAppRunner.cpp,
line 1604
###!!! ASSERTION: Setting main thread twice?: 'Error', file nsThread.cpp, line 393
###!!! ASSERTION: Setting main thread twice?: 'Error', file nsThread.cpp, line 393
###!!! ASSERTION: Setting main thread twice?: 'Error', file nsThread.cpp, line 393
###!!! ASSERTION: Setting main thread twice?: 'Error', file nsThread.cpp, line 393
###!!! ASSERTION: Setting main thread twice?: 'Error', file nsThread.cpp, line 393
###!!! ASSERTION: Setting main thread twice?: 'Error', file nsThread.cpp, line 393
###!!! ASSERTION: Setting main thread twice?: 'Error', file nsThread.cpp, line 393

BTW, is there better way to debug on Mac OSX?

Comment 25

[Conrad Carlen (not reading bugmail)]

> Because the crash does not happen when the primary language is set to Japanese

    Here's what I think it is: If the primary language is set to Japanese and
you have a Japanese file name, the whole path can be mapped to the dest
character set (Japanese). If the primary language is set to US, the name can't
be mapped into the dest charset (MacRoman). Not  only that, different nodes of
the path can have different encoding, so trying to map a path as a whole isn't
always going to work. There's a Apple technote on this in the Files group of
technotes.
    The reason this mapping has to take place is that the routine which we
normally use to get the full path (FSpGetFullPath) which returns a char* in the
OS charset, does not work with non-ASCII chars on OS X. Getting the path from
the OS as a Unicode path works (I tested it in these cases) but then we have to
convert back to a char* path and then run into this conversion problem.

You can debug (kind of) under OS X with CW7. You can email me about that.

Comment 26

[nhottanscp]

I agree that the conversion cannot succeed when the string contains something
not in the primary language. So GetPath() returns an error. We cannot really
avoid this unless we always use GetUnicodePath() in Mozilla.

But I think the crasher is more generic XPCOM error handling problem. I changed
nsLocalFile::GetPath to return always 'NS_ERROR_FAILURE'. Then Mozilla always
crashes, the same crash as the case with Japanese disk name.
I also tried that on Windows, chagned nsLocalFile::GetPath to return error
always, it crashes too.

Comment 27

[nhottanscp]

On start up, Mozilla cannot access "component.reg" and "component" directory,
XPCOM fails to initialize then leads to the crash.
It can be simulated on Windows.
In nsComponentManagerImpl::Init, change the return value from PlatformInit() to -1.
http://lxr.mozilla.org/seamonkey/source/xpcom/components/nsComponentManager.cpp#617

After some assertions, it crashes in nsComponentManagerImpl::FreeServices.
I think the same place as Mac OS X crash.

nsComponentManagerImpl::FreeServices() line 1734 + 3 bytes
NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 479
main(int 1, char * * 0x00481cf0) line 1638 + 8 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e992a6()

I change component to XPCOM and reassign to dougt.
Please take a look at this. We want at least to avoid the crash. 

Comment 28

[Conrad Carlen (not reading bugmail)]

Read my comment from 2001-11-01 18:34. Specifically, the problem is here:
http://lxr.mozilla.org/mozilla/source/xpcom/components/nsRegistry.cpp#542.
dougt's comment is especially true in this case.

Comment 29

[Conrad Carlen (not reading bugmail)]

Of course, even if we avoid the crash caused by this, the application is never
going to run anyway until GetPath(char**) is eradicated from nsIFile. That
involves a pretty huge API changing - bug 94323

Comment 30

[nhottanscp]

We want to avoid the crash first. Then we might need putting some kind of an
alert if possible.

Comment 31

[Daniel Veditz [:dveditz]]

So short of re-writing libreg (and I know everyone would like to jump at that
chance) an additional NR_RegOpenUsingDescriptor() API could be written, and then
nsRegistry could use nsIFile::Open() and pass in the handle.

NR_RegOpen currently uses the filename to return the same registry handle in
case two different callers open the same registry. This can easily be skipped,
but subsequent callers would then get a read-only handle so I suggest this
functionality be moved into nsRegistry itself.

Comment 32

[Rui Xu]

Bug 87831 is related to this:

1. On US language/locale, can repro crash with JA double-byte chars.
2. On JA language/locale, can repro crash with some JA double-byte chars and 
high ACSII chars.

Comment 33

[Yuying Long]

Attachment: screen shot for a example of above case 2.

Can not start up with the character "i ti" named hard drive. 
Notice the character is display as "?" in profile manager.

Comment 34

[Yuying Long]

On today's(11-13) trunk build:
If I change the hard drive name to the special character named above first, and
clear up registry and install a trunk build (e.g. 11-13), then can not start up
(crash) N6x.

Comment 35

[Doug Turner (:dougt)]

dan, over to you.  

You have already addressed many of the same issues that I would run into such as
file permissions, reg packing, reg standalone, ect.

Comment 36

[marina]

mozilla won't start up with non-ascii (french, german etc) name neither. I am
using US locale,renamiong my HD to Alt+0+201 and the profile manager crashes,
changing the summary.  

Comment 37

[Daniel Veditz [:dveditz]]

changing target milestone to a nomination. Not sure I can get to it by then (and
this is an old, old problem).

Comment 38

[Yuying Long]

-> nsbeta1

Comment 39

[Syd Logan]

Resetting milestone, only nsbeta1+ bugs can have a milestone on them, these are
niminated, but not yet plussed.

Comment 40

[Matthias Versen [:Matti]]

*** Bug 126384 has been marked as a duplicate of this bug. ***

Comment 41

[David Tolliver]

Attachment: Crash with "/" HD name

Crashes at startup with hard-drive name "/", goes away when I change the
hard-drive to a alphabetical string e.g. "rube".  This error occured with
Chimera 0.5.0. 

Finally, for the HD name change to have an effect I had to overwrite over the
original installation in "/Application" directory.

Comment 42

[David Tolliver]

Attachment: Crash with "/" HD name

Crashes at startup with hard-drive name "/", goes away when I change the
hard-drive to a alphabetical string e.g. "rube".  This error occured with
Chimera 0.5.0. 

Finally, for the HD name change to have an effect I had to overwrite over the
original installation in the "/Application" directory.

Comment 43

[timeless]

bounce. mls the crash is currently in your ballpark. i think this is the second
copy of this stack that i saw today.

Comment 44

[Greg K.]

The crashes in comment 41 and comment 42 have the same stack as bug 173215.

Why is this on Security: CAPS?

See also bug 160898.

Comment 45

[Simon Fraser [no longer active]]

Greg: that crash stack is typical of XPCOM init faililng (but the app continuing
to run anyway). The JS context is nil. XPCOM init can fail for a number of
reasons, so the stack doesn't say much.

Comment 46

[Conrad Carlen (not reading bugmail)]

> Finally, for the HD name change to have an effect I had to overwrite over the
original installation in the "/Application" directory.	

That suggests that, only when we register components, we hit this bug. Even
though one stack shows it crashed in nsScriptSecurityManager, that's not the
problem, just the 1st thing to suffer the woe of XPCOM not initializing properly.

BTW, running 10.2, I changed the name of my drive to "/", launched a fresh build
of the app so that components and chrome would be re-registered, and there was
no problem. This was with the Mach-0 build of mozilla, which has the same file
system as Chimera but is unlike CFM Mozilla.

Starting with comment 41, this should be a different bug because we're talking
about different apps with different code (CFM Mozilla vs. Chimera)

Comment 47

[Samir Gehani]

i18n triage team: need info.  Marina to test this.

Comment 48

[marina]

per i18n triage meeting: nsbeta1-

Comment 49

[Benjamin Smedberg]

I believe we've fixed startup in this case.