Closed Bug 26252 Opened 25 years ago Closed 25 years ago

[PP] Crash-At launch Mozilla after setenv LANG to ja_JP.EUC

Categories

(Core :: Internationalization, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: teruko, Assigned: cata)

References

Details

(Keywords: crash, Whiteboard: [pdt+])

After you set environment to Japanese, Mozilla will crash.

Steps of reproduce
1. setenv LANG ja_JP.EUC
2. setenv LC_ALL ja_jp.EUC
3. ./mozilla to launch mozilla

The console windows says 
"nsCollationUnix::Initialize  mLocale=ja_JP.EUC
  nsCollationUnix::Initialize  mCharset=EUC-JP
  nsCollationUnix::Initialize  mLocale=ja_JP.EUC
  nsCollationUnix::Initialize  mCharset=EUC-JP"

After this message is displayed, the mozilla will crash.

Tackback incident #4827397,
     
     libuconv.so + 0x990b (0x4048090b) 
     libuconv.so + 0x99fd (0x404809fd) 
     libuconv.so + 0x9954 (0x40480954) 
     libuconv.so + 0x996c (0x4048096c) 
     libuconv.so + 0x996c (0x4048096c) 
     libuconv.so + 0x996c (0x4048096c) 
     libuconv.so + 0x996c (0x4048096c) 
     libuconv.so + 0x937e (0x4048037e) 
     libuconv.so + 0x9025 (0x40480025) 
     libuconv.so + 0x888f (0x4047f88f) 
     libuconv.so + 0x85f3 (0x4047f5f3) 
     libxpcom.so + 0x60ca9 (0x400f5ca9) 
     libxpcom.so + 0x5f08e (0x400f408e) 
     libxpcom.so + 0x64268 (0x400f9268) 
     libxpcom.so + 0x64ba9 (0x400f9ba9) 
     libxpcom.so + 0x64f81 (0x400f9f81) 
     libxpcom.so + 0x651f8 (0x400fa1f8) 
     librdf.so + 0x346f7 (0x408cf6f7) 
     librdf.so + 0x618c5 (0x408fc8c5) 
     librdf.so + 0x5fec2 (0x408faec2) 
     librdf.so + 0x60b92 (0x408fbb92) 
     libnecko.so + 0x1a850 (0x4049f850) 
     libnecko_res.so + 0x3ccc (0x404adccc) 
     libnecko_file.so + 0x2ea1 (0x404b3ea1) 
     libnecko.so + 0xcbb0 (0x40491bb0) 
     libnecko.so + 0xc640 (0x40491640) 
     libxpcom.so + 0x66333 (0x400fb333) 
     libxpcom.so + 0x662c3 (0x400fb2c3) 
     libxpcom.so + 0x66e6a (0x400fbe6a) 
     libwidget_gtk.so + 0x22ccf (0x40508ccf) 
     libwidget_gtk.so + 0x22a9d (0x40508a9d) 
     libglib-1.2.so.0 + 0xe52a (0x4069f52a) 
     libglib-1.2.so.0 + 0xfbe6 (0x406a0be6) 
     libglib-1.2.so.0 + 0x101a1 (0x406a11a1) 
     libglib-1.2.so.0 + 0x10341 (0x406a1341) 
     libgtk-1.2.so.0 + 0x8c209 (0x405c8209) 
     libwidget_gtk.so + 0x2318a (0x4050918a) 
     libnsappshell.so + 0x17a22 (0x4044ca22) 
     mozilla-bin + 0x2395 (0x0804a395) 
     mozilla-bin + 0x2704 (0x0804a704) 
     libc.so.6 + 0x181eb (0x4021b1eb) 
  
Tested 2000020209 Linux Commercial build.  This does not happen in 2000020110 Linux Commercial build.
Keywords: beta1
Looks like an i18n problem to me.
Assignee: valeski → ftang
FreeBSD? Teruko, why you test FreeBSD ?
Looks like some RDF code calling unicode converter in the initialization.
Status: NEW → ASSIGNED
Corrected OS to Linux.
OS: FreeBSD → Linux
change componment to internationalization and accept it as M14
Component: DOM Level 0 → Internationalization
Target Milestone: M14
I cannot reproduce this in my local build. Maybe the crash is introduce in the 
last several days and my build have not pick them up yet. Teruko, can  you 
reproduce this easily ?
There 2 different cases.
1. After the console windows says 
"nsCollationUnix::Initialize  mLocale=ja_JP.EUC
  nsCollationUnix::Initialize  mCharset=EUC-JP
  nsCollationUnix::Initialize  mLocale=ja_JP.EUC
  nsCollationUnix::Initialize  mCharset=EUC-JP"

Mozilla launchs, then it will crash.

2. After the console windows says 
"nsCollationUnix::Initialize  mLocale=ja_JP.EUC
  nsCollationUnix::Initialize  mCharset=EUC-JP
  nsCollationUnix::Initialize  mLocale=ja_JP.EUC
  nsCollationUnix::Initialize  mCharset=EUC-JP"

Mozilla will not launch, then it will crash.

I did not see this problem in 2000020110 Linux Commercial build.

QA Contact: desale → teruko
Adding "crash" keyword.
Keywords: crash
Whiteboard: [pdt+]
The stack trace is almost meaninless. It do not have symbol (see  Incident 
ID4827397 ). The only clue I got is it crash 
after some recursive code.(4 time  of 0x996c )

     
     libuconv.so + 0x990b (0x4048090b) 
     libuconv.so + 0x99fd (0x404809fd) 
     libuconv.so + 0x9954 (0x40480954) 
     libuconv.so + 0x996c (0x4048096c) 
     libuconv.so + 0x996c (0x4048096c) 
     libuconv.so + 0x996c (0x4048096c) 
     libuconv.so + 0x996c (0x4048096c) 
     libuconv.so + 0x937e (0x4048037e) 

I do not remember I have recursive code inside uconv/src. I remember cata's 
recent check in of nsCharestMenu have QuickSort which is recursive. I think the 
following line may be the case which cause the crash.

In PRInt32 nsCharsetMenu::QSPartition(nsMenuItem ** aArray, PRInt32 aLow,
                                   PRInt32 aHigh, nsICollation * aCollation
    while (CompareItemTitle(aArray[right], pivot_item, aCollation) > 0) right--;

right could be -1 , right ? the aArray[right] will cause crash!!!

[Cata, please do not put the body of if or while in the same line of the 
condiction. It is not readable and not not easy to debug.]

Reassign to cata to investigate.
Assignee: ftang → cata
Status: ASSIGNED → NEW
ftang,
You cannot reproduce with your local build?
Damn! That code wasn't supposed to go in anymore: I was going replace it with 
the standard QSort routine we alredy had in Mozilla. But I totally forgot... 
Sorry guys, I'll have a fix in less than an hour.
Status: NEW → ASSIGNED
Severity: normal → critical
Fixed. I'm using now the available NS_QuickSort. Please verify that crash is 
gone.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I verified this in 2000020908 Linux build.
Status: RESOLVED → VERIFIED
*** Bug 27071 has been marked as a duplicate of this bug. ***
*** Bug 26530 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.