Closed Bug 118408 Opened 23 years ago Closed 21 years ago

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

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
OSF/1
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: clkao, Assigned: danm.moz)

References

Details

(Keywords: crash) 

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.
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 ()
Severity: major → critical
FreeBSD Nightly Build 2002010507 also crashes.
Also crashes Linux 2002010408. See also bug 70775.
Keywords: crash
should this alert dialog be modal?
-> XPApps: GUI Features
Assignee: sgehani → blaker
Component: Search → XP Apps: GUI Features
QA Contact: claudius → sairuh
akkana, are you able to repro?
Assignee: blaker → akkana
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.)
Assignee: akkana → blaker
mass moving open bugs pertaining to find in page/frame to pmac@netscape.com as
qa contact.

to find all bugspam pertaining to this, set your search string to
"AppleSpongeCakeWithCaramelFrosting".
QA Contact: sairuh → pmac
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.
The talkback-ID for my crash is: TB3638295E.
Talkback server is apparently having problems. CC:ing stephend@netscape.com
since he promised to help me get the stack.
Sorry, Talkback was horked for a few hours, can you please submit a new incident
ID?  Thanks...
The new talkback ID is: TB3655911E.

Setting status to NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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() 
*** Bug 132595 has been marked as a duplicate of this bug. ***
1.0rc1 Mozilla {Build ID: 2002041711} Debian Linux kernel 2.4.17
Talkback Incident ID TB5400908Z
dup of bug 127295 ? Stack look similar within the last comments: bug comment 14
here and bug 127295 comment 5.
*** Bug 145748 has been marked as a duplicate of this bug. ***
*** Bug 127295 has been marked as a duplicate of this bug. ***
Summary: find crashes when reaching the end of search → find crashes when reaching the end of search [GlobalWindowImpl::RunTimeout()]
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.
Assignee: blaker → danm
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)
It has stopped happening to me also.  I'm running 1.0rc3 now planning on
upgrading to 1.0 shortly.
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.
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
OS: Linux → All
QA Contact: pmac → sairuh
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.
Status: NEW → RESOLVED
Closed: 21 years ago
OS: All → OSF/1
Resolution: --- → WORKSFORME
I can no longer reproduce the bug using the steps in my comment 9. Verifying.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.