Closed Bug 388439 Opened 17 years ago Closed 15 years ago

crash coming from nsCharsetMenu::AddRef

Categories

(Core :: Internationalization, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: kairo, Assigned: smontagu)

Details

(Keywords: crash, Whiteboard: [needs stack evaluated for usefulness - cycle collector])

Attachments

(1 file)

Attached file stacktrace
Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/200707171313 SeaMonkey/2.0a1pre

I just hit an interesting crash that says to be at a stackframe called "0x00000000 in ?? ()" but it came from nsCharsetMenu::AddRef - see attached stacktrace.
Not sure what I did to hit it, from seeing cycle collector there I guess I haven't had to explicitely do something to hit it.
Whiteboard: [needs stack evaluated for usefulness - cycle collector]
Looking at the stack, I have no idea what's going on here.
kairo: can you:

cd $objdir/xpfe/components/intl
rm -f nsCharsetMenu.i
make nsCharsetMenu.i
perl -pi.0 -e 's{(# \d)}{// $1}' nsCharsetMenu.i
perl -pi.1 -e 'next if m{//}; s!{!{\n!g;s!}!\n}\n!g' nsCharsetMenu.i
g++ -c nsCharsetMenu.i -o nsCharsetMenu.o
make

At least, for me that generates a file which compiles (it doesn't link, but i'm assuming that's because my tree hasn't built in ages).

That should give you a vaguely useful line number when you crash.
Actually, let's close this down, it's more than two years old and it's been ages since I ran on debug builds - also I crash rarely enough that I'm pretty sure that I don't hit this regularly - esp. in the light that I didn't have a clue how I triggered it in the first place.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: