212415 - crash when closing a window opened by java script [@ GlobalWindowImpl::RunTimeout ]

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Christian Koch]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030624

When typing more than 10 characters in the textfield two windows pop up. When
you close them mozilla crashes.
The testcase I created is from a german site (sms.de) for sending short messages
(GSM). I extracted the important java script functions from their site and
changed some values, but the behaviour is the same!

Reproducible: Always

Steps to Reproduce:
1. type > 10 characters in the textfield
2. two windows will open
3. close them

Actual Results:  
mozilla crashes, it's not freezing, the whole program simply terminates. (ps -A
doesn't show any mozilla prozesses)

Expected Results:  
not crash ;-)

Comment 1

[Christian Koch]

Attachment: testcase

Comment 2

[Andrew Schultz]

might be a dupe of bug 173308

Comment 3

[Christian Koch]

I just tried this with the last nightly (Mozilla/5.0 (X11; U; Linux i686; de-AT;
rv:1.5a) Gecko/20030711). I still have the same problem, and as bug 173308 is
fixed, this might be another problem.

Comment 4

[Olivier Cahagne]

confirming crash using a debug build 20030701 on Linux:

JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code: 
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMTreeWalker.nextNode]"  nsresult: 
"0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome:
//global/content/bindings/button.xml :: fireAccessKeyButton :: line 94"  data: 
no]
 
WARNING: nsTimeoutImpl::Release() proceeding without context., file 
nsGlobalWindow.cpp, line 5202
WEBSHELL- = 7
WARNING: nsTimeoutImpl::Release() proceeding without context., file 
nsGlobalWindow.cpp, line 5202
WEBSHELL- = 6
###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 
'mRawPtr != 0', file ../../../dist/include/xpcom/nsCOMPtr.h, line 668
Break: at file ../../../dist/include/xpcom/nsCOMPtr.h, line 668
 
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 2332)]
0x421b595a in GlobalWindowImpl::RunTimeout(nsTimeoutImpl*) (this=0x8e36e20,
    aTimeout=0x8eff070) at nsGlobalWindow.cpp:5100
5100          rv = timeout->mTimer->InitWithFuncCallback(TimerCallback, timeout,
(gdb) bt
#0  0x421b595a in GlobalWindowImpl::RunTimeout(nsTimeoutImpl*) (
    this=0x8e36e20, aTimeout=0x8eff070) at nsGlobalWindow.cpp:5100
#1  0x421b6407 in GlobalWindowImpl::TimerCallback(nsITimer*, void*) (
    aTimer=0x8fe0410, aClosure=0x8eff070) at nsGlobalWindow.cpp:5391
#2  0x407fd27c in nsTimerImpl::Fire() (this=0x8fe0410) at nsTimerImpl.cpp:382
#3  0x407fd462 in handleTimerEvent(TimerEventType*) (event=0x42e081f8)
    at nsTimerImpl.cpp:447
#4  0x407f39b0 in PL_HandleEvent (self=0x42e081f8) at plevent.c:671
#5  0x407f3851 in PL_ProcessPendingEvents (self=0x811e460) at plevent.c:606
#6  0x407f5d86 in nsEventQueueImpl::ProcessPendingEvents() (this=0x811e4d8)
    at nsEventQueue.cpp:387
#7  0x41cc6410 in event_processor_callback (data=0x811e4d8, source=6,
    condition=GDK_INPUT_READ) at nsAppShell.cpp:188
#8  0x41cc5d9d in our_gdk_io_invoke (source=0x818ec88, condition=G_IO_IN,
    data=0x815e4d8) at nsAppShell.cpp:72
#9  0x4030c7d6 in g_io_channel_unix_get_fd () from /usr/lib/libglib-1.2.so.0
#10 0x4030f3ee in g_idle_remove_by_data () from /usr/lib/libglib-1.2.so.0
#11 0x4030f199 in g_idle_remove_by_data () from /usr/lib/libglib-1.2.so.0
#12 0x4030e174 in g_main_run () from /usr/lib/libglib-1.2.so.0

Comment 5

[Phil Schwartau]

Reassigning to DOM Events for further triage; doesn't look
like a JS Engine issue -

Comment 6

[Hermann Schwab]

crash on Win98, Talkback TB21819253H, so changing OS to ALL
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030711

Comment 7

[Andrew Schultz]

Attachment: simpler and less evil testcase

type anything in the textarea.
get 2 alert dialogs: "foo" and "bar".
after closing both, Mozilla crashes.

Comment 8

[Harshal Pradhan]

This is somewhat similar to what was happening in bug 178810. As far as I can
see, we can end up doing extra releases on timeout objects when some timeout is
cleared from a inside a "nested" timeout.

Comment 9

[Harshal Pradhan]

Attachment: This makes us not crash on the two testcases above

I'm not even sure this fixes everything, I get a headache trying to work out
all the possibilites with "nested" timers  :-)

... and I dont know how long we can just keep adding flags.

Comment 10

[Harshal Pradhan]

Comment on attachment 127876 [details] [diff] [review]
This makes us not crash on the two testcases above

jst, what do you think about this fix ?

Comment 11

[Harshal Pradhan]

Ummmm ... I thought I did this already. Sorry for the spam. 

Comment 12

[Johnny Stenback (:jst)]

Comment on attachment 127876 [details] [diff] [review]
This makes us not crash on the two testcases above

I get a headache every thime I look at this code too, but this makes a lot of
sense to me, I think this is the right thing to do. I can't see how the old
code would've done the right thing in the nested timer cases if timeouts were
cleared.

sr=jst

Comment 13

[Harshal Pradhan]

Checked in. 

Crashes should be fixed. We still sometimes throw "extra" popups on these
testcases, but that is just the old bug about modal-dialogs not blocking all js.