383120 - crash on executing window.open javascript popup [@ nsTextControlFrame::SetValue]

Status: RESOLVED DUPLICATE of bug 386254

Description

[Jerome Borsboom]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5pre) Gecko/20070603 BonEcho/2.0.0.5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5pre) Gecko/20070603 BonEcho/2.0.0.5pre

Firefox intermittently crashes with a SIGSEGV on opening a popup window with window.open javascript code.

Reproducible: Sometimes

Steps to Reproduce:
1. clicking the 'tekstlink' link in the middle of the given URL
2.
3.
Actual Results:  
a crash with SIGSEGV

Expected Results:  
appearance of a new popup window

Have tried a clean install and a new profile, but this does not resolve the issue.

The same crash can be intermittently evoked when clicking 'Internetbankieren' in the blue bar on the page http://www.rabobank.nl/particulieren/

OS:
Linux nb_knorkaan 2.6.20.11 #1 SMP PREEMPT Thu May 3 20:52:41 CEST 2007 i686 GNU/Linux

Comment 1

[Jerome Borsboom]

Created attachment 267134 [details]
stack backtrace

Comment 2

[Jerome Borsboom]

A critical element in the crash seems to be GetFormControlFrame in nsHTMLInputElement::SetValueInternal returning a non-NULL value when clicking the link described above. In that case, the crash happens. When GetFormControlFrame returns NULL, the window pops up as expected.

Comment 3

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5pre) Gecko/20070604 BonEcho/2.0.0.5pre
WFM.

Comment 4

[Adam Guthrie]

Stack is similar to the one in bug 301270. It would be great if you could attach a minimized testcase including steps on what to do to crash.

Comment 5

[Jerome Borsboom]

Created attachment 267169 [details]
testcase using window.open

this minimal testcase crashes my firefox when repeatedly clicking the link and closing the popup window

Comment 6

[Jerome Borsboom]

bug 357030 also has a similar stack trace

Comment 7

[Vlad Sukhoy]

Works for me,  Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/2007051502 Firefox/2.0.0.4

It does seem odd that timer routines are in the stack frame.. Maybe some extension is to blame...

Comment 8

[Jerome Borsboom]

a method that seems to trigger the bug in 100% of the cases for me:

* run firefox in gdb
* set a breakpoint on nsAppShell::Spindown
* run the test testcase which should trigger the breakpoint
* continue execution which leads to a SIGSEGV with the same stack backtrace


I have no idea why, but this bug seems to be introduced by the commit from bug 368501. When I undo this commit in the current cvs 1.8 branch, the testcase above does not crash firefox anymore.

Comment 9

[Olli Pettay [:smaug]]

Works for me, 1.8 branch/Linux (x86/Fedora7 and x86_64/Fedora5)

Comment 10

[H. Montoliu]

At ubuntu's bug tracker we have received 6 crashes with this stacktrace [1]. Btw I cannot reproduce the test case proposed in comment #5.

[1] https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/89090 

Comment 11

[Martijn Wargers (dead)]

I added a testcase (with enhanced privileges) in bug 373586 that crashes with this stacktrace.

Comment 12

[Daniel Veditz [:dveditz]]

How would a bug that was post-1.8 branch be relevant to this bug? or to flip it around, why isn't that test case here rather than added to a fixed bug?

Comment 13

[Daniel Veditz [:dveditz]]

Don't see how we can block on an unconfirmed bug. Renominate if there's more progress here.

Comment 14

[Alexander Sack]

we still see dupes coming in from 2.0.0.4/1.5.0.12 ... so confirming as a first step.

Comment 15

[Alexander Sack]

note: the attached testcase doesn't crash for me.

Comment 16

[Martijn Wargers (dead)]

A patch was checked in in bug 386254, that fixed a crash with a similar stacktrace.
This was checked in on the 1.8.1.5 and 1.8.0.13 branch, so hopefully that fixes it.