154282 - Mozilla fails to read the profile directory under some Asian locales

Status: RESOLVED EXPIRED

(Core :: Internationalization, defect)

Description

[Shanmugavelu Shanmuganathan (gone)]

I set the LANG=ja_JP.deckanj. Then started mozilla.
In the Profile selection window I selected a profile.
At this point Mozilla pops up a dialog saying that 
"Mozilla cannot use the profile "Profilename" because the directory containing
the profile cannot be found. 
Please choose another profile or create a new one".

This message is not true. On C locale I can run mozilla without a 
problem. 
This doesn't happen with Mozilla 1.0RC3 or 1.0.

Comment 1

[Shanmugavelu Shanmuganathan (gone)]

I get the following debug messages, which I believe lead to this bug.

###!!! ASSERTION: failed to create encoder: '0', file nsUNIXCharset.cpp, line 369
###!!! Break: at file nsUNIXCharset.cpp, line 369
###!!! ASSERTION: unable to use nl_langinfo(CODESET): '0', file
nsUNIXCharset.cpp, line 293
###!!! Break: at file nsUNIXCharset.cpp, line 293
###!!! ASSERTION: unable to convert locale to charset using deprecated config:
'0', file nsUNIXCharset.cpp, line 126
###!!! Break: at file nsUNIXCharset.cpp, line 126
###!!! ASSERTION: unable to convert locale to charset using deprecated config:
'0', file nsUNIXCharset.cpp, line 336

Comment 2

[Roy Yokoyama]

I am working on the similar issue (file i/o) in Windows OS; but no idea in Linux. 
better assign to shanjian.

Comment 3

[Jim Dunn]

could this be a dup of http://bugzilla.mozilla.org/show_bug.cgi?id=147333

Comment 4

[Shanjian Li]

This bug probably is not a dup of 147333. Some other things happened in branch
seems fixed the problem. I guess patch for bug 148026 probably will too. I
suggest you give a try. Bug 143132 might also provide some hints.

Comment 5

[Shanmugavelu Shanmuganathan (gone)]

Mozilla crashed when I tried the patch from bug 148026. 

Thread received signal SEGV
stopped at [virtual nsresult nsWindow::SetTitle(const class nsString&):2278
0x3ffbef72650]
   2278   encoder->GetMaxLength(aTitle.get(), len, &platformLen);

Let me dig more on this.

Comment 6

[Shanmugavelu Shanmuganathan (gone)]

Mozilla crashed, on a Tru64 UNIX, when I start this on ja_JP.deckanji locale. 
This doesn't happen on other Japanese locales. It works fine 
in ja_JP.sdeckanji. 
	I see that whenever the charset is set to deckenji, mozilla crashes.
This happens with the trunk build. It looks like the it scans through 
all the available charsets and when it reads "deckenji"  the encoder is 
set to null. 

181   encoder = do_CreateInstance(contractid.get(), &res);
(ladebug) p contractid
class nsCAutoString {
  mBuffer = "@mozilla.org/intl/unicode/encoder;1?charset=deckanji";     
  union {
    mStr = 0x11fffa0e8="@mozilla.org/intl/unicode/encoder;1?charset=deckanji";
    mUStr = 0x11fffa0e8;
  };   // class nsCString::nsStr
  mLength = 52;                   // class nsCString::nsStr
  mCapacityAndFlags = 63;         // class nsCString::nsStr


At this point the encoder is NULL.
(ladebug) p encoder
class nsCOMPtr<nsIUnicodeEncoder> { 
  mRawPtr = 0x0; 
}

which leads to crash at "nsWindow.cpp":2286

2286   encoder->GetMaxLength(aTitle.get(), len, &platformLen)

Any idea why the encoder is "0" only at this locale?

Comment 7

[Alec Flett]

localizations or locales? locales makes the most sense to me

Comment 8

[Andrew Hagen]

Wasn't sure. Thanks.

Comment 9

[Martin Mokrejs]

Hello guys, why isn't this bug still fixed? For example, there are 2 reports on
Tru64 Unix openend too. :)

Comment 10

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 11

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.