If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED WORKSFORME

Status

SeaMonkey
UI Design
--
critical
VERIFIED WORKSFORME
16 years ago
9 years ago

People

(Reporter: clkao, Assigned: Dan M)

Tracking

({crash})

Trunk
x86
OSF/1
crash

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
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

Comment 2

16 years ago
FreeBSD Nightly Build 2002010507 also crashes.

Comment 3

16 years ago
Also crashes Linux 2002010408. See also bug 70775.
Keywords: crash

Comment 4

16 years ago
should this alert dialog be modal?

Comment 5

16 years ago
-> 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

Comment 7

16 years ago
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

Comment 9

16 years ago
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

16 years ago
The talkback-ID for my crash is: TB3638295E.

Comment 11

16 years ago
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...

Comment 13

16 years ago
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() 

Comment 15

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

Comment 16

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

Comment 17

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

Comment 18

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

Comment 19

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

Updated

16 years ago
Summary: find crashes when reaching the end of search → find crashes when reaching the end of search [GlobalWindowImpl::RunTimeout()]

Comment 20

16 years ago
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

Comment 21

16 years ago
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

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

Comment 23

16 years ago
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

16 years ago
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
(Assignee)

Comment 25

15 years ago
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
Last Resolved: 15 years ago
OS: All → OSF/1
Resolution: --- → WORKSFORME

Comment 26

15 years ago
I can no longer reproduce the bug using the steps in my comment 9. Verifying.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

Updated

9 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.