59345 - Crash when window closed by a key under high loads (was: "Find" dialog crashes when ESC key is pressed TWICE, but not when the Cancel button is pressed)

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect, P3)

Comment 1

[Matthias Versen [:Matti]]

WFM on WIN2k build 2000110604 trunk

Comment 2

[Arjen Hommersom]

wfm on linux build 2000110621

Comment 3

[Asa Dotzler [:asa]]

Ang Chin Han, this bug does not contain enough information to be useful.  Please
review the Bug Writing Guidelines at
http://www.mozilla.org/quality/bug-writing-guidelines.html and consider using
the Bugzilla helper to report any future bugs
http://www.mozilla.org/quality/help/bug-form.html .  If you can reproduce this
on a current nightly build and can include the kinds of information requested in
the guidelines please reopen the bug.
Thanks for your help in testing Mozilla and reporting bugs.
-Asa
Based on the summary this is Worksforme with 110808 Mozilla trunk build on
RedHat6.2  

Comment 4

[timeless]

vrfy invalid.

Comment 5

[Ang Chin Han]

My bad.

Linux nightly (20000809xx, but reproducible from M18 onwards).
Freshly generated profile.

http://www.mozilla.org/ loaded and displayed.

Ctrl-F, and the Find Dialog is displayed.
ESC pressed TWICE in quick succession.
Seg fault.

Note that ESC has to be pressed twice. (I never noticed that until I
tried to reproduce).

Comment 6

[Ang Chin Han]

Upon further testing, I found that this bug is not limited to the Find dialog,
but the Preferences, Open Web Location, Save As, Open File dialogs as well.

Some of them crash with just one ESC, but sometimes (Find Dialog) doesn't
crash at all even with two quick ESCs. It _might_ be due to how busy Mozilla
is at the moment, e.g. rendering or loading a page when ESC is pressed.

Comment 7

[Doron Rosenberg (IBM)]

coudl you get a .sea. build and thus generate a talkback reprot?

Comment 8

[Ari Pollak]

Also, are you starting with a fresh mozilla directory, or are you overwriting
old nightlies? And lastly, have you tried with the latest nightlies?

Comment 9

[sairuh (rarely reading bugmail)]

over to xp apps gui... modality issue?

Comment 10

[sairuh (rarely reading bugmail)]

hrm, i couldn't repro this using mozilla trunk bits 2000.11.08.08-trunk on linux
[running redhat 6.2, enlightenment wm]. tried with Find, Open Web Location and
Preferences dialogs.

marking wfm. Ang, could you repro this using a more recent build?

Comment 11

[Samuel Sieb]

I can reproduce it with Build 2000110908.  Only one ESC is necessary.
I opened a page in a new window, CTRL-F to bring up the find dialog, press ESC.
Talkback ID: TB20737069K

Comment 12

[Samuel Sieb]

More information:  You MUST open a page in a new window, click in the document
to give it keyboard focus, bring up a dialog using the keyboard, then press ESC.
Crash in the "Open Web Location" dialog, Talkback ID: TB20737365Q

Comment 13

[Ang Chin Han]

Using today's mozilla-i686-pc-linux-gnu-sea.tar.gz (20001109)

Help | About says:
Mozilla/5.0 (X11; U; Linux 2.2.15 i686; en-US; m18) Gecko/20001109

Default profile (not imported), Fresh install (deleted old installation).

Crash only occurs when the CPU is busy, so trying this with:
1. Slow CPU
2. CPU busy compiling stuff on background
3. Big, maximized mozilla window (1280x1000+), complicated page to render
   when dialog is gone.
4. ESC-ing the preferences dialog (which is bigger and more complicated)

might help.

FWIW, I could repro this by:
0. Delete old profiles.
1. Starting the installer, installing in a new directory (mozilla starts up
   automatically after that)
2. Start a huge compilation in the background (I used postgresql-7.0.2)
3. Maximize Mozilla window (1127x900)
4. Click on URL bar and type 'about:'
5. Open up the Preferences dialog (Edit | Preferences).
6. Center dialog on the browser window.
7. ESC --> Crash (90% of the time; 10% of the time, I'm lucky).

Using WindowMaker. Could be modality issue?

talkback.xpi for this build doesn't seem to be generating a report.

samuel: Thanks. I was beginning to feel like that kid from Sixth Sense: "I see
wierd bugs".

Comment 14

[Asa Dotzler [:asa]]

info from talkback reports:
   libgdk-1.2.so.0 + 0x241c2 (0x405eb1c2)
     libgdk-1.2.so.0 + 0x1448d (0x405db48d)
     libgdk-1.2.so.0 + 0x143eb (0x405db3eb)
     libwidget_gtk.so + 0x14e5f (0x404b0e5f)
     libwidget_gtk.so + 0x151d9 (0x404b11d9)
     libwidget_gtk.so + 0x150aa (0x404b10aa)
     libgdk-1.2.so.0 + 0x15b80 (0x405dcb80)
     libglib-1.2.so.0 + 0x10736 (0x40608736)
     libglib-1.2.so.0 + 0x10d43 (0x40608d43)
     libglib-1.2.so.0 + 0x10eec (0x40608eec)
     libgtk-1.2.so.0 + 0x785d9 (0x4055e5d9)
     libwidget_gtk.so + 0xd2fc (0x404a92fc)
     libnsappshell.so + 0xcc0a (0x40455c0a)
     mozilla-bin + 0x6275 (0x0804e275)
     mozilla-bin + 0x6845 (0x0804e845)
     libc.so.6 + 0x18cae (0x40270cae)

unable to reproduce with 11104 mozilla trunk build.

Comment 15

[sairuh (rarely reading bugmail)]

bah, midair collision with Asa.

anyhow, reopening per Samuel and Ang's latest info --thx!

Comment 16

[Samuel Sieb]

I'm not sure what build Asa was referring to, but i can still reproduce on build
2000111008.  Opening the dialog with the keyboard has to be the very first thing
you do in a new window and sometimes it doesn't crash, but try it a few times
and it will.

Comment 17

[Ang Chin Han]

Tried this on Windows (M18 build). Does not crash.

Tried 20001113 on linux. Crash.

Not really limited to the ESC key. It seems to me like any window that could be
closed by a key, for instance, the ENTER key on various windows, will
consistently crash mozilla under high loads (for me, anyway).

Alt-F4 (bound to "Close Window" under my WindowMaker 0.62.1), would also crash
mozilla for any window, including the main browser window under high loads.

Hmm... I'll try this with a different window manager after this.

No talkbacks generated from this .sea nightly build, even though I asked it to
install QA stuff (talkback.xpi is suspiciously small - 3245 bytes only)

Changing Summary to reflect this.

Comment 18

[Ang Chin Han]

argh. I too had trouble reproducing this bug consistently under KDE 1.2's window
manager. Might be all the fluff I have running under Window Maker.

This is what I found:
- Two compilations in the background for higher load than one.
- One key stroke has lower probability of crashing mozilla than two key strokes
  (like double clicking).
- Not window manager related, though I had a harder time repro. this under KDE.
  Wierd.

This might explain why mozilla (for linux) is unstable for some people but
okay for others (slow, overloaded computer vs fast computer). You really need
a high load to repro. this bug consistently.

Comment 19

[Bill Law]

I'm adding danm to the cc: list.  I really suspect that this is more his bug
than Ben's (although I wouldn't stoop so low as to reassign it to him).

Comment 20

[Ang Chin Han]

Build 2000112016

I think I've tracked down the cause of the crash.
I've been using Mandrake 7.1's gtk+-1.2.7-4mdk.i586.rpm and
glib-1.2.7-4mdk.i586.rpm

After I've upgraded to gtk+-1.2.8-1.i386.rpm and glib-1.2.8-1.i386.rpm
from http://www.gtk.org/, I've been unable to reproduce the crash.

This is using the same mozilla build, so I'm reasonably certain the fault
either lies in glib/gtk 1.2.7 or Mandrake's build of it. Mandrake do not have a
glib/gtk 1.2.8 that I can test without upgrading therest of my system, so I
can't tell if it's the glib/gtk version or Mandrake's.

samuel: Can you please upgrade glib/gtk if you are using the older version
and confirm this bugfix?

Also, where do we document or otherwise publicize this problem with Mandrake/
gtk? At least it'll solve the stablity of mozilla for the affected people.
OTOH, should mozilla check for problematic versions of glib/gtk and warn the
user?

Comment 21

[Fabian Guisset]

Samuel can you reproduce with the last comment's information? If not we should 
mark this worksforme. If yes -- it has to be another reason :(
Fabian.

Comment 22

[Samuel Sieb]

That seems to fix it.
Also, seems to fix the "hit enter and die" for dialog boxes as well.

Comment 23

[sairuh (rarely reading bugmail)]

mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)