When you specify the profile directory to specific non-ascii directory (にほんご), Netscape crashes. Steps of reproduce 1. Create the directory name "c:\にほんご" (Unicode point, U+306B, U+307B, U+3093, U+3054) 2. Launch Profile Manager 3. Click on Create Profile button 4. Click on Next button 5. Click on Choose Folder 6. Choose the directory you created in step #1 and click Finish button Netscape will crash. If Netscape does not crash at this time, 7. Select the profile name you created in Select User Profile directory Netscape will crash. I tried the different combination of the characters for profile directory to create the profile, "にほんご" (Unicode point, U+306B, U+307B, U+3093, U+3054) is only directory name for profile I found Netscape crashes so far. This happens only in Winnt 4.0J and Win2kJ (and Whisler beta2 Japanese). This does not happen in Win98J. I could not reproduce this on Linux and Mac build also. Tested 5-25, 5-29, 5-30 Win32 build.

Added intl keyword and changed QA contact to myself.

Teruko, do you have a talkback result? Cc to ccarlen@netscape.com since this may be Profile Manger BackEnd.

No. I did not get the talkback report.

This is not regression. I could reproduce this in 6.0rtm.

If you can reproduce it with 6.0 rtm, can you reproduce it with a current build and tell why it's happening?

This happens with the current build.

Naoki and I tried this on his machine. We could reproduce this as following steps. 1. Create the directory name "c:\?É?Ù?ñ?²" (Unicode point, U+306B, U+307B, U+3093, U+3054) 2. Launch Profile Manager 3. Click on Create Profile button 4. Click on Next button 5. Click on Choose Folder and type some profile name 6. Choose the directory you created in step #1 and click Finish button 7. Select the profile name you created in Select User Profile directory Netscape will crash. After Netscape crashes, if you start Profile manager and select the profile name which you created in step #5, Netscape will launch.

I don't have a system on which I can create a dir with the given name but one place I'd be curious about is this: http://lxr.mozilla.org/seamonkey/source/profile/src/nsProfile.cpp#1322 Naoki, can you see if we make it through this point OK? Is the given Unicode path converted into an nsILocalFile and is the heap OK at that point? After that point, I don't see what difference the non-ACSII path would make.

Looks like the problem is happening earlier. I set a break point at line 1322. But I can crash before reaching the break point. I chose the Japanese directory and hit cancel then it crashed without hitting the break point. When I did not cancel then at the break point, the unicode string was valid. But later it crashed after selected the created profile (or any profile).

When I got to step six, clicking the finish button did nothing, and after clicking cancel, the profile did not exist. timeless said the same thing happened for him.

Chad what is you environment, so does it reproducible on non Japanese OS?

I'm in Windows 2000 (english), running 2001060104.

I would like to try set a break point right after the user selected the Japanese name directory. Conrad, any suggestion for where to put a break point?

The folder is selected in .js here: http://lxr.mozilla.org/seamonkey/source/profile/resources/content/newProfile1_2.js#84 I'd put a break on nsIFilePicker::Show() and then on nsLocalFIle::GetUnicodePath()

naoki/frank - can someone in intl group take this bug, that may give us the best chance of tracking it down quickly.

okay, reassign to nhotta

It seems like the thing gets wrong in nsFilePicker::Show. The code to handle the directory selection ("modeGetFolder" option for nsIFilePicker), that is also used in mail (for attachment context menu). And I can reproduce the crash with mail too, so this is not a profile manager specific. Looks like the memory is corrupted after calling ether API ::SHBrowseForFolder or ::SHGetPathFromIDList. It does not crash if I hard code the Japanese string in the source code without calling those API. Not sure if we are calling those API incorrectly or tere is a problem in the API. Change component to xptoolkit and cc to trudelle, who is responsible for windows nsIFilePicker?

See bug 66175; no, the use of the API is wrong, and we can get an ABW, which is I presume the root problem. On the other bug, jband lays out the simple fix.

After I copied the directory string to a buffer of length MAX_PATH+1 and use it for "pszDisplayName", the crash is gone, both cases the profile manager and the mail attachment.

Naoki, I'd sleep easier if you changed PL_strcpy to PL_strncpy (with appropriate length argument). I'm not sure you couldn't construct an nsILocalFile with some bogus path that was longer than MAX_PATH and I think we should protect against overrunning your new buffer on the copy. r=law with that change.

sr=blizzard

While looking at this bug, I noticed initialDir is never freed. Can you add an nsMemory::Free call before the return NS_OK? Better yet, char* initialDir should be replaced with a string class that will destroy itself when it leaves scope...

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

Question about the MAX_PATH constant when used like this: char dirBuffer[MAX_PATH+1]; Does MAX_PATH mean the number of bytes or the number of characters? Could the size in bytes on a Japanese system be MAX_PATH * sizeof(wchar_t) ?

http://msdn.microsoft.com/library/psdk/shellcc/shell/structures/BROWSEINFO.htm pszDisplayName Address of a buffer to receive the display name of the folder selected by the user. The size of this buffer is assumed to be MAX_PATH bytes.

r=law

a=blizzard on behalf of drivers for the trunk

checked in

I verified the fix in the 060613 trunk and 060612 0.9.1 builds and it doesn't crash, but it doesn't give you any useful information either. In my local debug build, it says "Cannot create profile C:\????\whatever". I think I know what's happening. The wide-character path is getting converted to ASCII somewhere along the line, and it tries to use the actual ???? folder. In Windows, you can't create a folder named ????. This new issue should be a new bug. I'll file it.

See bug 84384.