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)
Tracking
()
VERIFIED
FIXED
M14
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.
Comment 2•25 years ago
|
||
FreeBSD? Teruko, why you test FreeBSD ? Looks like some RDF code calling unicode converter in the initialization.
Status: NEW → ASSIGNED
Comment 4•25 years ago
|
||
change componment to internationalization and accept it as M14
Component: DOM Level 0 → Internationalization
Target Milestone: M14
Comment 5•25 years ago
|
||
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 ?
Reporter | ||
Comment 6•25 years ago
|
||
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
Updated•25 years ago
|
Whiteboard: [pdt+]
Comment 8•25 years ago
|
||
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
Assignee | ||
Comment 10•25 years ago
|
||
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.
Updated•25 years ago
|
Severity: normal → critical
Assignee | ||
Comment 11•25 years ago
|
||
Fixed. I'm using now the available NS_QuickSort. Please verify that crash is gone.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•25 years ago
|
||
I verified this in 2000020908 Linux build.
Status: RESOLVED → VERIFIED
Comment 13•25 years ago
|
||
*** Bug 27071 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
*** 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.
Description
•