Version: (using KDE KDE 3.1.4) Installed from: Debian testing/unstable Packages Compiler: gcc-3.3.2 OS: Linux Konqueror crashes every time when I trying to open the following html page: <html> <body> <iframe id='tst'></iframe> <script> doc=window.frames['tst'].document; doc.write("<script src=1.js></sc"+"ript>"); </script> </body> </html> with 1.js file in the same directory containing: document.close(); I've put same files on my home page for convinience: http://lorien.s2s.msu.ru/1.html I'm using Debian unstable GNU/Linux distribution (package konqueror-3.1.3)
konqueror: htmltokenizer.cpp:158: void khtml::HTMLTokenizer::reset(): Assertion `m_executingScript == 0' failed. Dirk?
*** Bug 69247 has been marked as a duplicate of this bug. ***
*** Bug 71967 has been marked as a duplicate of this bug. ***
*** Bug 76234 has been marked as a duplicate of this bug. ***
*** Bug 80107 has been marked as a duplicate of this bug. ***
*** Bug 81417 has been marked as a duplicate of this bug. ***
*** Bug 81490 has been marked as a duplicate of this bug. ***
I still can reproduce this bug on new KDE 3.2.2 I'm using Debian GNU/Linux distribution (unstable) kdelibs, kdebase package version 3.2.2-2 gcc compiler version 3.3.3, kernel 2.6.6 on ix86 processor
*** Bug 81664 has been marked as a duplicate of this bug. ***
*** Bug 81487 has been marked as a duplicate of this bug. ***
*** Bug 82367 has been marked as a duplicate of this bug. ***
*** Bug 82566 has been marked as a duplicate of this bug. ***
*** Bug 79334 has been marked as a duplicate of this bug. ***
*** Bug 82556 has been marked as a duplicate of this bug. ***
Exactly this bug occurs on hundreds of JavaScript-enabled sites (that's why it has so many duplicates). With JavaScript enabled, Konqueror crashes on every site that uses banners from adnet.ru (that is, on 30% of Russian sites I visit) as well as on many other sites. That's a big pain if I had many tabs opened in the browser. So it is quite critical, at least for me. It is NOT Debian-specific. RedHat people found that as well. This bug seems to be introduced in KDE 3.1 and is still there in every next release. Is there any developer working on it?
It's a bit harder to fix. I suggest echo "127.0.0.1 www.adnet.ru" >> /etc/hosts as work around
Stephan, thanks for the workaround. Can you please explain what exactly is happening? I have backtrace only. Probably you tried to fix it and can explain it better than backtrace :). I want to try to fix it but I don't want to reinvent the wheel.
see #1 - the HTML tokenizer doesn't like this
*** Bug 83780 has been marked as a duplicate of this bug. ***
*** Bug 83211 has been marked as a duplicate of this bug. ***
*** Bug 87441 has been marked as a duplicate of this bug. ***
*** Bug 87736 has been marked as a duplicate of this bug. ***
Anybody working on this bug? It's really annoying... (Also affected Safari 1.2.2)
*** Bug 89040 has been marked as a duplicate of this bug. ***
*** Bug 91592 has been marked as a duplicate of this bug. ***
*** Bug 91816 has been marked as a duplicate of this bug. ***
*** Bug 93489 has been marked as a duplicate of this bug. ***
*** Bug 93590 has been marked as a duplicate of this bug. ***
*** Bug 93997 has been marked as a duplicate of this bug. ***
*** Bug 94059 has been marked as a duplicate of this bug. ***
Boosting severity, this the most reported crash in KHTML. I had a few suggestions ping-ponged with Germain back in October. We better go back find a solution.
*** Bug 96206 has been marked as a duplicate of this bug. ***
Created attachment 9101 [details] Bugfix: Make DOM::DocumentImpl::close() not delete the khtml::HTMLTokenizer object on close with scripts running from that HTML tokenizer object This patches KHTML to not delete the in-use khtml::HTMLTokenizer object that it has in use when document.close() is called from within JavaScript on a web page. To fix the bug, I added another virtual method to khtml::Tokenizer - const bool isRunningScriptFromTokenizer(). It's default implementation returns 'false', since it appears that only the HTML tokenizer executes scripts during the parsing of the page. The HTML tokenizer was extended with support for the method, which returns true if the current execution context is within any scripting context. Konqueror doesn't crash at this instance of the code, so I'm going to assume that this patch fixes the bug. I can't say for certain that it does because I don't know all of the possible test cases.
*** Bug 95287 has been marked as a duplicate of this bug. ***
The fix by Sarah really works! Thanks!
*** Bug 98094 has been marked as a duplicate of this bug. ***
*** Bug 96751 has been marked as a duplicate of this bug. ***
Is the patch included in CVS? And, more important, will it be included in kde 3.4 final? I didn't have a single problem with konqueror since I patched the sources and recompiled.
No, the patch isn't in CVS yet.
I'm working on this. Patch #33 is a turnaround that was already proposed by Allan some time ago, but it's not the proper fix. We need something more generally solving crossframe scripting (responsible for other crashes on early popup closing).
Created attachment 9491 [details] proposed patch when a cross-frame script writes to a document, we have to toggle parsing on again and reset the part's complete state. We also need to have the tokenizer check itself regularly, to know when it is finished (we can't rely on the script issuing a close() )
Created attachment 9639 [details] proposed patch attachment #9491 [details] is fine for scripts document.writing on closed documents, but does not address cases where this happens before the tokenizer is deleted, such as for onLoad triggered scripts. In that latter case, attachment #9101 [details] still makes sense, so I attached a version merging the two. regression tested ; tested on every duplicate of this bug. Please review. Unless there are objections, I'll commit this shortly.
CVS commit by ggarand: - sanitize part/tokenizer state (for cross-document scripts). - don't delete a tokenizer still executing a script on explicit close (patch from Allan Sandfeld and Sarah <sarah@b0rked.dhs.org>) BUG: 68523 + crashes on early pop-up closing. M +18 -0 ChangeLog 1.382 M +12 -0 khtml_part.cpp 1.1091 M +1 -0 khtml_part.h 1.279 M +26 -1 html/htmltokenizer.cpp 1.298 M +8 -3 html/htmltokenizer.h 1.85 M +6 -2 xml/dom_docimpl.cpp 1.308 M +4 -0 xml/xml_tokenizer.h 1.26
Thank you Germain. I've just finished to test your patch... This *WAS* my most hated bugs.!!! Excelent work!!! Gentoo users. You can take a patch from here: http://bugs.gentoo.org/show_bug.cgi?id=78058
Hello again. Gentoo developers need this patch to be backported to 2.3.2. Please can anybody do this? Or plese tell us that the patch I posted at http://bugs.gentoo.org/show_bug.cgi?id=78058 does it's work... Thank you very much again, Peter.
I'm sure, projects other than Gentoo and FreeBSD will appreciate a back-ported patch too :-). 3.4 is far from release...
mmh, OK, I can go for a backport but that will take some time, I have to rebuild a branch and do some testing.
Javascript is still crashing konq in 3.4. On the kde-redhat list, we have multiple confirmations on multiple releases. The only commonality is KDE 3.4. Try going to ebay with javascript enabled. I don't think it has anything to do with banners, though root cause may be the same.
Strange. I do not have such problem. Although I'm using gentoo. And may be I used the wrong link. Can you give me direct link? I've tried www.ebay.com. And played a bit... No problems there.
Well, updown.ru didn't crash my konqueror (although the design and colors are horrible, it's the worst pr0nsite i've seen). I'm running kde 3.4 on gentoo (compiled using gcc 3.4.3)
I'm also using kde in gentoo. No crashes.
In particular, try "Ask seller a question" on eBay. Find an item -- any item. Click on the "Ask seller a question" on the top right side of the item's page. On the new page, that opens, click into the TEXTAREA to start typing the question. Last I tried that, Konqueror ran out of stack space (JavaScript-code went into recursion) and died. A different bug from the one reported here.