118408 - find crashes when reaching the end of search [GlobalWindowImpl::RunTimeout()]

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[clkao]

Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.7+) Gecko/20020105

to reproduce:
1. open a web page
2. Ctrl-F to searach something that exist in the page
3. press enter in the search dialog until the alert
   "the text you entered was not found" appeaers
4. press esc in the search dialog
5. press esc in the alert dialog

note that if the search term is not found in the page at all,
pressing esc in both windows in the order above won't crash
mozilla.

Comment 1

[clkao]

here is the dump trace:

(gdb) bt
#0  0x28e73d0c in GlobalWindowImpl::DropTimeout ()
   from /home/clkao/mozilla-bsd/components/libjsdom.so
#1  0x28e74182 in GlobalWindowImpl::TimerCallback ()
   from /home/clkao/mozilla-bsd/components/libjsdom.so
#2  0x282aafef in nsTimerImpl::Process () from /home/clkao/mozilla/libxpcom.so
#3  0x282ab04d in handleMyEvent () from /home/clkao/mozilla/libxpcom.so
#4  0x282a6b05 in PL_HandleEvent () from /home/clkao/mozilla/libxpcom.so
#5  0x282a6a0d in PL_ProcessPendingEvents () from /home/clkao/mozilla/libxpcom.so
#6  0x282a7b3f in nsEventQueueImpl::ProcessPendingEvents () from
/home/clkao/mozilla/libxpcom.so
#7  0x2872808f in nsAppShell::SetDispatchListener ()
   from /home/clkao/mozilla-bsd/components/libwidget_gtk.so
#8  0x28727dbe in keysym2ucs () from
/home/clkao/mozilla-bsd/components/libwidget_gtk.so
#9  0x284a5a35 in g_io_unix_dispatch () from /usr/local/lib/libglib12.so.3
#10 0x284a71e6 in g_main_dispatch () from /usr/local/lib/libglib12.so.3
#11 0x284a77f3 in g_main_iterate () from /usr/local/lib/libglib12.so.3
#12 0x284a79a8 in g_main_run () from /usr/local/lib/libglib12.so.3
#13 0x283c52ed in gtk_main () from /usr/X11R6/lib/libgtk12.so.2
#14 0x28728638 in nsAppShell::Run () from
/home/clkao/mozilla-bsd/components/libwidget_gtk.so
#15 0x286f8b7e in nsAppShellService::Run ()
   from /home/clkao/mozilla-bsd/components/libnsappshell.so
#16 0x8050a93 in _start ()
#17 0x8051478 in main ()
#18 0x804c581 in _start ()

Comment 2

[Kang-min Liu]

FreeBSD Nightly Build 2002010507 also crashes.

Comment 3

[Olav Vitters]

Also crashes Linux 2002010408. See also bug 70775.

Comment 4

[alge]

should this alert dialog be modal?

Comment 5

[Samir Gehani]

-> XPApps: GUI Features

Comment 6

[sairuh (rarely reading bugmail)]

akkana, are you able to repro?

Comment 7

[Akkana Peck]

I don't see it on my system.  But it looks like it's probably a timing issue
related to some timeout that's being set.  I don't know why either of these
dialogs would need a timeout for anything; perhaps it's something the owning
window is setting?

Interestingly, I was just working with cmanske trying to track down a different
crash on dismissing a dialog, where something ends up getting deleted twice
(addref'ed once too many) which causes a crash.  This makes me suspect that we
have a bug in the window/dialog system, which has nothing to do with the code
inside the dialog ...  (That crash is reproducible but involves code that isn't
yet checked in, so I can't point you to it.)

I'm reassigning to xpfe folks (there's no dialog component, so I'll leave it in
GUI Features) since there's nothing in the crash that makes it look like it's
the find backend.  Staying tuned, though, since I also want to know what's
causing these crashes.  Let me know if you need the patch that shows a
reproducible case.  (cmanske's example was seen on Windows, BTW.)

Comment 8

[sairuh (rarely reading bugmail)]

mass moving open bugs pertaining to find in page/frame to [e-mail] as
qa contact.

to find all bugspam pertaining to this, set your search string to
"AppleSpongeCakeWithCaramelFrosting".

Comment 9

[André Dahlqvist]

I just saw this with 2002-03-01-16 on Linux. biesi on #mozillazine could also
reproduced it.

Reproducable: always
Steps to reproduce:

1) Go to http://www.google.com
2) Press Ctrl-F
3) Enter "smallbanana" in the text field (or some other non-existant word).
4) *Hold down* ENTER for around 5 seconds and let the "...not found" dialogs
stack on top of eachother.
5) Press ESC to remove the dialogs, one after the other.

Result: Mozilla will crash after a few dialogs have been closed.

Below I will attach the stack of this crash.

Comment 10

[André Dahlqvist]

The talkback-ID for my crash is: TB3638295E.

Comment 11

[André Dahlqvist]

Talkback server is apparently having problems. CC:ing [e-mail]
since he promised to help me get the stack.

Comment 12

[[e-mail] (gone - use [e-mail] instead)]

Sorry, Talkback was horked for a few hours, can you please submit a new incident
ID?  Thanks...

Comment 13

[André Dahlqvist]

The new talkback ID is: TB3655911E.

Setting status to NEW.

Comment 14

[[e-mail] (gone - use [e-mail] instead)]

GlobalWindowImpl::RunTimeout()
GlobalWindowImpl::TimerCallback()
nsTimerImpl::Process()
handleMyEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xeeb0 (0x40377eb0)
libglib-1.2.so.0 + 0x10578 (0x40379578)
libglib-1.2.so.0 + 0x10b83 (0x40379b83)
libglib-1.2.so.0 + 0x10c35 (0x40379c35)
nsAppShell::DispatchNativeEvent()
nsXULWindow::ShowModal()
nsWebShellWindow::ShowModal()
nsContentTreeOwner::ShowAsModal()
nsWindowWatcher::OpenWindowJS()
nsWindowWatcher::OpenWindow()
nsPromptService::DoDialog()
nsPromptService::Alert()
nsPrompt::Alert()
GlobalWindowImpl::Alert()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
GlobalWindowImpl::RunTimeout()
GlobalWindowImpl::TimerCallback()
nsTimerImpl::Process()
handleMyEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xeeb0 (0x40377eb0)
libglib-1.2.so.0 + 0x10578 (0x40379578)
libglib-1.2.so.0 + 0x10b83 (0x40379b83)
libglib-1.2.so.0 + 0x10c35 (0x40379c35)
nsAppShell::DispatchNativeEvent()
nsXULWindow::ShowModal()
nsWebShellWindow::ShowModal()
nsContentTreeOwner::ShowAsModal()
nsWindowWatcher::OpenWindowJS()
nsWindowWatcher::OpenWindow()
nsPromptService::DoDialog()
nsPromptService::Alert()
nsPrompt::Alert()
GlobalWindowImpl::Alert()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
GlobalWindowImpl::RunTimeout()
GlobalWindowImpl::TimerCallback()
nsTimerImpl::Process()
handleMyEvent()
PL_HandleEvent()
PL_ProcessEventsBeforeID()
processQueue()
nsVoidArray::EnumerateForwards()
nsAppShell::ProcessBeforeID()
handle_gdk_event()
libgdk-1.2.so.0 + 0x17477 (0x40349477)
libglib-1.2.so.0 + 0x10578 (0x40379578)
libglib-1.2.so.0 + 0x10b83 (0x40379b83)
libglib-1.2.so.0 + 0x10c35 (0x40379c35)
nsAppShell::DispatchNativeEvent()
nsXULWindow::ShowModal()
nsWebShellWindow::ShowModal()
nsContentTreeOwner::ShowAsModal()
nsWindowWatcher::OpenWindowJS()
nsWindowWatcher::OpenWindow()
nsPromptService::DoDialog()
nsPromptService::Alert()
nsPrompt::Alert()
GlobalWindowImpl::Alert()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
GlobalWindowImpl::RunTimeout()
GlobalWindowImpl::TimerCallback()
nsTimerImpl::Process() 

Comment 15

[André Dahlqvist]

*** Bug 132595 has been marked as a duplicate of this bug. ***

Comment 16

[Fuzzy Gorilla]

1.0rc1 Mozilla {Build ID: 2002041711} Debian Linux kernel 2.4.17
Talkback Incident ID TB5400908Z

Comment 17

[Olivier Cahagne]

dup of bug 127295 ? Stack look similar within the last comments: bug comment 14
here and bug 127295 comment 5.

Comment 18

[bugzilla.mozilla.org]

*** Bug 145748 has been marked as a duplicate of this bug. ***

Comment 19

[André Dahlqvist]

*** Bug 127295 has been marked as a duplicate of this bug. ***

Comment 20

[Blake Ross]

reassigning to someone that knows more about windows than me.  Is this really
happening for all linux users?  seems like there'd be more dups if so.

Comment 21

[alge]

it's not happening to me anymore. That might be because I changed wm (sawfish ->
blackbox), dunno. Or some miracle might have happened.

(linux, cvs trunk build from today)

Comment 22

[bugzilla.mozilla.org]

It has stopped happening to me also.  I'm running 1.0rc3 now planning on
upgrading to 1.0 shortly.

Comment 23

[André Dahlqvist]

Not happening for me with a 1.0-branch build from today. I tried to use my
previous steps in comment 9, but it does not crash anymore.

Comment 24

[timeless]

i crashed using mozilla1.0release
tb7264782z
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
i had a lot of trouble trying to close the error dialog, it pretty much refused
to close, my guess is that i crashed when it finally decided to close.

note that bug 112707 is for a similar crash

Comment 25

[Dan M]

I can't reproduce this. The underlying problem could well have been fixed in the
intervening year. Note that the original bug as reported could only happen on
*unix because it's the only one (of the big three, anyway) that allows the user
to close the search dialog before closing the alert, so I suspect the above
comment 24 is something else (assuming that hasn't been magically fixed in the
meantime as well). Closing WFM.

Comment 26

[André Dahlqvist]

I can no longer reproduce the bug using the steps in my comment 9. Verifying.