82962 - Crash on switching character coding

Status: VERIFIED DUPLICATE of bug 80988

(Core :: Internationalization, defect, P1)

Description

[Koike Kazuhiko]

Linux build with gcc 2.95(mozilla-gcc295-i686-pc-linux-gnu.tar.gz)
crashes if you switch character coding.

Comment 1

[Tom Mraz]

I'm seeing this crash too (I also use the gcc295 build).
It crashes for at least 10 days.

Comment 2

[nhottanscp]

IQA, could you help reproducing this?

Comment 3

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 4

[Teruko Kobayashi]

Commercial linux build has not been launched.  I checked this on 5-29-09 Linux
trunk build, but I could not reproduce it. 

Comment 5

[Teruko Kobayashi]

[e-mail], please ask somebody to test in the latest build (after 
5-29).  I checked this in 5-27 mozilla build, but I could not reproduce this, 
either.

Comment 6

[nhottanscp]

Katakai san, have you seen this problem?

Comment 7

[ji]

I don't see this problem either with 05/29 comm. linux build on my RH6.2J 
system.

Comment 8

[Tom Mraz]

I see this crash under linux gcc295 2001052921 build but not under the
linux egcs 2001052921 build (it works fine with this build). 
I can produce only unusable stack trace with the build (there are no function
names only NSGetModule()). If I would know how to make my gdb to produce the
valid stack trace I would make it.

The gcc295 build crashes just anytime when I try change the character coding
using the View->Character Coding->Central European

Comment 9

[Tom Mraz]

Here is the beginning of the stack trace:

#0  0x00000000 in ?? ()
#1  0x41083551 in NSGetModule ()
   from /home/mraz/mozilla/components/libgklayout.so
#2  0x41081453 in NSGetModule ()
   from /home/mraz/mozilla/components/libgklayout.so
#3  0x41022bc0 in NSGetModule ()
   from /home/mraz/mozilla/components/libgklayout.so
#4  0x40cfe1fb in NSGetModule ()
   from /home/mraz/mozilla/components/libgkcontent.so
#5  0x40fc2178 in NSGetModule ()
   from /home/mraz/mozilla/components/libgklayout.so
#6  0x40c56d2a in NSGetModule ()
   from /home/mraz/mozilla/components/libgkcontent.so
#7  0x40c41810 in NSGetModule ()
   from /home/mraz/mozilla/components/libgkcontent.so
#8  0x40c41941 in NSGetModule ()
   from /home/mraz/mozilla/components/libgkcontent.so
#9  0x41080ac3 in NSGetModule ()
   from /home/mraz/mozilla/components/libgklayout.so
#10 0x40fc31f5 in NSGetModule ()
   from /home/mraz/mozilla/components/libgklayout.so
#11 0x40fc2fbe in NSGetModule ()
...

Comment 10

[nhottanscp]

> If I would know how to make my gdb to produce the valid stack trace
> I would make it.
Brian, Katakai san, any advice?

Comment 11

[Frank Tang]

crash bug, mark moz0.9.2

Comment 12

[nhottanscp]

KOIKE san, what is your environment, do you still see the crash?

Comment 13

[Koike Kazuhiko]

Crash happened on LASER5 Linux 6.4 and Debian GNU/Linux.

http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=991

I'll try to reproduce this later.

Comment 14

[Hideo Oshima]

I can reprodice on Debian GNU/Linux unstable.

My environment:
Kernel : 2.4.5
glibc : 2.2.3
gtk+ : 1.2.10
XF86 : 4.0.3

Please tell me if you need any more information.

Comment 15

[nhottanscp]

Reassign to bstell.

Katakai san, have you seen this on Solaris?

Comment 16

[kill this account]

Tom/Hideo/Koike:

Since I am unable to reproduce this I'm struggling to figure out how to
proceed. Perhaps a few questions will help if you don't mind:

Did you create a new profile?

Can you supply a particular URL this happens on?

From what encoding to what encoding?

Do you have autodetect turned on?

Is there a long delay or alot of disk activity before it crashes
(infinite recursion)?

Comment 17

[Frank Tang]

pdt+ base on 6/11 pdt meeting.

Comment 18

[Hideo Oshima]

Brian,

1. I created new profile and tried. The same result happned.

2. The crush happens at many pages. For example, this page.

3. On this page, EUC-JP to ISO-8859-1.

4. Autodetect is usually on.
   (By the way, I turned autodetect off then crushed.)
   However I create new profile, at the time autodetect is off,
   and tried. Switching char coding also caused crush.

5. No delay, no disk accress when it crushes. 
   It does not seem in infinete recursion.

Comment 19

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 20

[kill this account]

Okay. I downloaded mozilla-gcc295-i686-pc-linux-gnu.tar.gz from
http://ftp.mozilla.org/pub/mozilla/nightly/2001-05-27-09-trunk/
and also installed libstdc++
http://www.beonex.de/download/communicator/0.6/req/libstdc++-2.95.2-7mdk.i586.rp
m

Indeed, it does crash when switching character encoding.

Now I need to figure out how to build a debug version of this.

Comment 21

[kill this account]

from email:

>     Install the cpp295, gcc295 & libstdc++295 rpms from 
>     /u/cltbld/cls/rpms/rpm3 .
> 
>     Then add the following lines to your .mozconfig:
>     CC=/usr/gcc295/bin/gcc
>     CXX=/usr/gcc295/bin/g++
> 
>     That's it.
> 
>     - cls

Comment 22

[kill this account]

the gcc295 version this is not used in a commercial version:
   remove pdt+ from "Status Whiteboard"
   move to 0.9.3

Comment 23

[Frank Tang]

agree with bstell's action. keep in moz0.9.3

Comment 24

[cls]

I'm pretty sure that this is a -O2 problem.   My gcc 2.95.3 -g build can switch
encodings without a problem.  My gcc 2.95.3 -O2 build crashes.  I can't see the
stack because it locks my X session.  The gcc295 nightlies are built using gcc
2.95.3 -O2 as well.  I'll fire off gcc 2.95.3 -O & egcs 1.1.2 -O2 builds to verify.

Comment 25

[kill this account]

This appears to be a compilier optimization issue not an i18n issue.

Reassigning to Chris Seawood <[e-mail]>

Comment 26

[Ben Bucksch (:BenB)]

*** This bug has been marked as a duplicate of 80988 ***

Comment 27

[cls]

So just for the record, the gcc 2.95.3 -O build does not exhibit the problem
while the egcs 1.1.2 -O2 build does.

Comment 28

[cls]

verified dupe. stack traces are the same.