Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc 3.3 OS: Linux URL: http://www.theglobeandmail.com/servlet/story/RTGAM.20031007.wdavis/BNStory/Front/ No testcase available yet. The site is horribly broken with KHTML though. Mouse handling in particular. First crash has problems here: #49 0x426bdfe9 in KJS::Interpreter::evaluate(KJS::UString const&, KJS::Value const&) (this=0xfffffe00, code=@0xbfffd770, thisV=@0xbfffd780) at interpreter.cpp:166 #50 0x4257ff0b in KJSProxyImpl::evaluate(QString, int, QString const&, DOM::Node const&, KJS::Completion*) (this=0x83229a8, filename= {static null = {static null = <same as static member of an already seen type>, d = 0x80539d8, static shared_null = 0x80539d8}, d = 0x0, static shared_null = 0x80539d8}, baseLine=844, str=@0xbfffda00, n=@0xbfffd950, completion=0xbfffd8a0) at kjs_proxy.cpp:148 #51 0x42423613 in KHTMLPart::executeScript(QString const&, int, DOM::Node const&, QString const&) (this=0x82a1ff8, filename=@0xbfffd970, baseLine=844, n=@0xbfffd950, script=@0xbfffda00) at khtml_part.cpp:971 #52 0x4248a56d in khtml::HTMLTokenizer::scriptExecution(QString const&, QString const&, int) (this=0x841b420, str=@0xbfffda00, scriptURL=@0xbfffd940, baseLine=843) at ../../khtml/khtmlview.h:110 #53 0x4248a0d8 in khtml::HTMLTokenizer::scriptHandler() (this=0x841b420) at htmltokenizer.cpp:399 #54 0x42489e59 in khtml::HTMLTokenizer::parseSpecial(khtml::DOMStringIt&) ( this=0x841b420, src=@0x841b534) at htmltokenizer.cpp:317 #55 0x4248c482 in khtml::HTMLTokenizer::parseTag(khtml::DOMStringIt&) ( this=0x841b420, src=@0x841b534) at htmltokenizer.cpp:1125 #56 0x4248d9dd in khtml::HTMLTokenizer::write(QString const&, bool) ( this=0x841b420, str=@0xbfffdcf0, appendData=false) at htmltokenizer.cpp:1259 Other crashes tend to happen when following links on that site if you can manage to find the right place to click to activate a link. Form elements also don't work there.
*** Bug 65854 has been marked as a duplicate of this bug. ***
On the rdiff-backup site, the clickable region for the link is alongside the actual link text; on the same horizontal line. http://rdiff-backup.stanford.edu/
I don't know if all the old corruption still exists, but now it causes an assert failure: #10 0x4251bb86 in khtml::RenderBlock::createLineBoxes(khtml::RenderObject*) ( this=0x8535758, obj=0x8535bc0) at bidi.cpp:408 #11 0x4251bcf2 in khtml::RenderBlock::constructLine(khtml::BidiIterator const&, khtml::BidiIterator const&) (this=0x8535758, start=@0xbfffd4e0, end=@0xbfffd4d0) at ../../khtml/rendering/render_object.h:117 #12 0x4251d845 in khtml::RenderBlock::layoutInlineChildren(bool) ( this=0x8535758, relayoutChildren=true) at bidi.cpp:1183 #13 0x4252032e in khtml::RenderBlock::layoutBlock(bool) (this=0x8535758, relayoutChildren=true) at render_block.cpp:498 #14 0x4254aee9 in khtml::RenderTableCell::layout() (this=0x8535758) at render_table.cpp:1618 #15 0x4254aa25 in khtml::RenderTableRow::layout() (this=0x8535734) at render_table.cpp:1537 #16 0x42533d8d in khtml::RenderContainer::layout() (this=0x85356d8) at render_container.cpp:325 #17 0x42545a5c in khtml::RenderTable::layout() (this=0x853563c) at render_table.cpp:267 #18 0x42522b86 in khtml::RenderBlock::insertFloatingObject(khtml::RenderObject*) (this=0x85355b8, o=0x853563c) at render_block.cpp:1288 #19 0x425213dd in khtml::RenderBlock::layoutBlockChildren(bool) ( this=0x85355b8, relayoutChildren=false) at render_block.cpp:695 #20 0x4252058f in khtml::RenderBlock::layoutBlock(bool) (this=0x85355b8, relayoutChildren=false) at render_block.cpp:500
I investigated and noticed that the problem with the link's active area being offset from the visual display of the links had to do with the CSS imports. This is all from http://www.globeandmail.com, the front page. It does not exhibit the crash, only the link visual/clickable offset bug. I think about pages linked from the front page will crash though. I narrowed it down to this line: #contentTable { position : relative; top : 112px; border:solid 3px #000000; width:770px; margin:15px auto 0 0; padding-top:0px; } I tested an alteration of that line (112px changed, now 0px): #contentTable { position : relative; top : 0px; border:solid 3px #000000; width:770px; margin:15px auto 0 0; padding-top:0px; } And it worked fine (the link location was synced correctly). The problem seems to be the mouseOver/Clicked event handling is working in a coordinate system that is not being affected by that CSS entry, or the math being done there is not taking the function into account. The CSS entry itself works fine in that it does affect correct change in the visual display of the page. I have not tested the pages which crash. I will report if I have time to test at some point. Sam M.
Upon further thinking, it seems the problem is that the math for the location of the pointer active areas are taking that CSS entry into account, even though the coordinate system they are based off already took that CSS entry into account. This is evident because the content (and links) appears correctly with an offset of 112px from the top, but the area to click each link is 112px down from the link. This means the CSS entry has 2x the effect on the clickable area, only 1x on the visual display. This is seen on all link on the front page of www.globeandmail.com. All except the links in the top banner, which had not been (and shouldn't have been) affected by the offending CSS entry. The bug also affects form fields (as can be seen in the poll/vote cell). The submit button shows 'animation' for mouse over in two positions:The correct position (visually over the button), and an offset of 112px. Only the offset position can actually be clicked though (and submits as normal). The ratio buttons only show the animation of mouseOver for the correct position, but are only selectable by clicking in the offset position. A text field acts the same as ratio button. By mouseOver i mean windowManager level stuff, not js. Hope this helps, heres to 3.2! Sam M.
*** Bug 69416 has been marked as a duplicate of this bug. ***
still a problem 12/19/2003
Still a problem, 1/14/2004 on: http://www.globeandmail.com/servlet/story/RTGAM.20040114.wbush0114/BNStory/International/ [New Thread 16384 (LWP 1310)] 0x412c1477 in waitpid () from /lib/libpthread.so.0 #0 0x412c1477 in waitpid () from /lib/libpthread.so.0 #1 0x407c55b7 in KCrash::defaultCrashHandler(int) (sig=6) at kcrash.cpp:246 #2 0x412bfbc5 in __pthread_sighandler () from /lib/libpthread.so.0 #3 <signal handler called> #4 0x41427151 in kill () from /lib/libc.so.6 #5 0x412bc9a1 in pthread_kill () from /lib/libpthread.so.0 #6 0x412bccab in raise () from /lib/libpthread.so.0 #7 0x41426d94 in raise () from /lib/libc.so.6 #8 0x41428548 in abort () from /lib/libc.so.6 #9 0x4142050c in __assert_fail () from /lib/libc.so.6 #10 0x41a60688 in khtml::RenderBlock::createLineBoxes(khtml::RenderObject*) ( this=0x85858ec, obj=0x8585e38) at bidi.cpp:408 #11 0x41a60908 in khtml::RenderBlock::constructLine(khtml::BidiIterator const&, khtml::BidiIterator const&) (this=0x85858ec, start=@0xbfffd830, end=@0xbfffd820) at bidi.cpp:454 #12 0x41a624eb in khtml::RenderBlock::layoutInlineChildren(bool) ( this=0x85858ec, relayoutChildren=true) at bidi.cpp:1183 #13 0x41a65fc6 in khtml::RenderBlock::layoutBlock(bool) (this=0x85858ec, relayoutChildren=true) at render_block.cpp:498 #14 0x41a95e73 in khtml::RenderTableCell::layout() (this=0x85858ec) at render_table.cpp:1618 #15 0x41a959bc in khtml::RenderTableRow::layout() (this=0x85858c8) at render_table.cpp:1537 #16 0x41a7c475 in khtml::RenderContainer::layout() (this=0x858586c) at render_container.cpp:347 #17 0x41a9139c in khtml::RenderTable::layout() (this=0x85857d0) at render_table.cpp:267 #18 0x41a68cf5 in khtml::RenderBlock::insertFloatingObject(khtml::RenderObject*) (this=0x858574c, o=0x85857d0) at render_block.cpp:1287 #19 0x41a66b52 in khtml::RenderBlock::layoutBlockChildren(bool) ( this=0x858574c, relayoutChildren=true) at render_block.cpp:695 #20 0x41a65fdf in khtml::RenderBlock::layoutBlock(bool) (this=0x858574c, relayoutChildren=true) at render_block.cpp:500 #21 0x41a95e73 in khtml::RenderTableCell::layout() (this=0x858574c) at render_table.cpp:1618 #22 0x41a959bc in khtml::RenderTableRow::layout() (this=0x8585728) at render_table.cpp:1537 #23 0x41a7c475 in khtml::RenderContainer::layout() (this=0x85856cc) at render_container.cpp:347 #24 0x41a9139c in khtml::RenderTable::layout() (this=0x8585630) at render_table.cpp:267 #25 0x41a67359 in khtml::RenderBlock::layoutBlockChildren(bool) ( this=0x85855c0, relayoutChildren=true) at render_block.cpp:822 #26 0x41a65fdf in khtml::RenderBlock::layoutBlock(bool) (this=0x85855c0, relayoutChildren=true) at render_block.cpp:500 #27 0x41a65bc8 in khtml::RenderBlock::layout() (this=0x85855c0) at render_block.cpp:418 #28 0x41a67359 in khtml::RenderBlock::layoutBlockChildren(bool) ( this=0x8585550, relayoutChildren=true) at render_block.cpp:822 #29 0x41a65fdf in khtml::RenderBlock::layoutBlock(bool) (this=0x8585550, relayoutChildren=true) at render_block.cpp:500 #30 0x41a65bc8 in khtml::RenderBlock::layout() (this=0x8585550) at render_block.cpp:418 #31 0x41a67359 in khtml::RenderBlock::layoutBlockChildren(bool) ( this=0x8584174, relayoutChildren=true) at render_block.cpp:822 #32 0x41a65fdf in khtml::RenderBlock::layoutBlock(bool) (this=0x8584174, relayoutChildren=true) at render_block.cpp:500 #33 0x41a95e73 in khtml::RenderTableCell::layout() (this=0x8584174) at render_table.cpp:1618 #34 0x41a959bc in khtml::RenderTableRow::layout() (this=0x85713a0) at render_table.cpp:1537 #35 0x41a7c475 in khtml::RenderContainer::layout() (this=0x8571344) at render_container.cpp:347 #36 0x41a9139c in khtml::RenderTable::layout() (this=0x8571260) at render_table.cpp:267 #37 0x41a67359 in khtml::RenderBlock::layoutBlockChildren(bool) ( this=0x85711f0, relayoutChildren=true) at render_block.cpp:822 #38 0x41a65fdf in khtml::RenderBlock::layoutBlock(bool) (this=0x85711f0, relayoutChildren=true) at render_block.cpp:500 #39 0x41a65bc8 in khtml::RenderBlock::layout() (this=0x85711f0) at render_block.cpp:418 #40 0x41a67359 in khtml::RenderBlock::layoutBlockChildren(bool) ( this=0x855bda4, relayoutChildren=true) at render_block.cpp:822 #41 0x41a65fdf in khtml::RenderBlock::layoutBlock(bool) (this=0x855bda4, relayoutChildren=true) at render_block.cpp:500 #42 0x41a65bc8 in khtml::RenderBlock::layout() (this=0x855bda4) at render_block.cpp:418 #43 0x41a67359 in khtml::RenderBlock::layoutBlockChildren(bool) ( this=0x855ba50, relayoutChildren=true) at render_block.cpp:822 #44 0x41a65fdf in khtml::RenderBlock::layoutBlock(bool) (this=0x855ba50, relayoutChildren=true) at render_block.cpp:500 #45 0x41a65bc8 in khtml::RenderBlock::layout() (this=0x855ba50) at render_block.cpp:418 #46 0x41a67359 in khtml::RenderBlock::layoutBlockChildren(bool) ( this=0x855b9dc, relayoutChildren=true) at render_block.cpp:822 #47 0x41a65fdf in khtml::RenderBlock::layoutBlock(bool) (this=0x855b9dc, relayoutChildren=true) at render_block.cpp:500 #48 0x41a65bc8 in khtml::RenderBlock::layout() (this=0x855b9dc) at render_block.cpp:418 #49 0x41ab4cac in khtml::RenderBody::layout() (this=0x855b9dc) at render_body.cpp:92 #50 0x41a67359 in khtml::RenderBlock::layoutBlockChildren(bool) ( this=0x855b924, relayoutChildren=false) at render_block.cpp:822 #51 0x41a65fdf in khtml::RenderBlock::layoutBlock(bool) (this=0x855b924, relayoutChildren=false) at render_block.cpp:500 #52 0x41a65bc8 in khtml::RenderBlock::layout() (this=0x855b924) at render_block.cpp:418 #53 0x41a67359 in khtml::RenderBlock::layoutBlockChildren(bool) ( this=0x855b840, relayoutChildren=false) at render_block.cpp:822 #54 0x41a65fdf in khtml::RenderBlock::layoutBlock(bool) (this=0x855b840, relayoutChildren=false) at render_block.cpp:500 #55 0x41a65bc8 in khtml::RenderBlock::layout() (this=0x855b840) at render_block.cpp:418 #56 0x41aad484 in khtml::RenderCanvas::layout() (this=0x855b840) at render_canvas.cpp:154 #57 0x419b26c8 in KHTMLView::layout() (this=0x82dc078) at khtmlview.cpp:579 #58 0x419b8dac in KHTMLView::timerEvent(QTimerEvent*) (this=0x82dc078, e=0xbffff140) at khtmlview.cpp:2153 #59 0x40c27c38 in QObject::event(QEvent*) (this=0x82dc078, e=0xbffff140) at kernel/qobject.cpp:741 #60 0x40c6227f in QWidget::event(QEvent*) (this=0x82dc078, e=0xbffff140) at kernel/qwidget.cpp:4630 #61 0x40bc796d in QApplication::internalNotify(QObject*, QEvent*) ( this=0xbffff520, receiver=0x82dc078, e=0xbffff140) at kernel/qapplication.cpp:2614 #62 0x40bc759d in QApplication::notify(QObject*, QEvent*) (this=0xbffff520, receiver=0x82dc078, e=0xbffff140) at kernel/qapplication.cpp:2502 #63 0x4073c6d5 in KApplication::notify(QObject*, QEvent*) (this=0xbffff520, receiver=0x82dc078, event=0xbffff140) at kapplication.cpp:503 #64 0x4004a38b in QApplication::sendEvent(QObject*, QEvent*) ( receiver=0x82dc078, event=0xbffff140) at qapplication.h:490 #65 0x40bb5afe in QEventLoop::activateTimers() (this=0x80c83e8) at kernel/qeventloop_unix.cpp:558 #66 0x40b6fce1 in QEventLoop::processEvents(unsigned) (this=0x80c83e8, flags=4) at kernel/qeventloop_x11.cpp:389 #67 0x40bdbc6a in QEventLoop::enterLoop() (this=0x80c83e8) at kernel/qeventloop.cpp:198 #68 0x40bdbb86 in QEventLoop::exec() (this=0x80c83e8) at kernel/qeventloop.cpp:145 #69 0x40bc7aed in QApplication::exec() (this=0xbffff520) at kernel/qapplication.cpp:2737 #70 0x4161978b in kdemain (argc=4, argv=0x8063770) at konq_main.cc:184 #71 0x408d2915 in kdeinitmain (argc=4, argv=0x8063770) at konqueror_dummy.cc:2 #72 0x0804e2fe in launch (argc=4, _name=0x806378c "konqueror", args=0x80637c1 "/home/cap", cwd=0x80637c1 "/home/cap", envc=41, envs=0x8063c71 "", reset_env=true, tty=0x0, avoid_loops=false, startup_id_str=0x8063c75 "kira;1074114110;543655;195") at kinit.cpp:604 #73 0x0804f60f in handle_launcher_request (sock=4) at kinit.cpp:1167 #74 0x0804fba3 in handle_requests (waitForPid=0) at kinit.cpp:1334 #75 0x08051128 in main (argc=3, argv=0xbffffb44, envp=0xbffffb54) at kinit.cpp:1797 #76 0x41413916 in __libc_start_main () from /lib/libc.so.6
*** Bug 71311 has been marked as a duplicate of this bug. ***
*** Bug 67214 has been marked as a duplicate of this bug. ***
*** Bug 72775 has been marked as a duplicate of this bug. ***
Created attachment 4200 [details] testcase Looks very tricky. The order of events seems to play a rather important role.
Render-tree for testcase: New RenderBlock = 0x81a07ec rendering/render_object.cpp:98 New RenderBlock = 0x81a0b30 rendering/render_object.cpp:98 New RenderBlock = 0x81a0ba0 rendering/render_flow.cpp:314 isInlineFlow = 0 Obj = 0x81a0ba0 This = 0x81a08a4 testkhtml: RenderCanvas(1): 0x81a0708 mmk zI: auto <> (0,0,796,0) [1-1] { mT: 0 qT: 0 mB: 0 qB: 0} layer=0x81a07a4 testkhtml: RenderBlock(1): 0x81a07ec mmk <html> (0,0,796,0) [1-1] { mT: 0 qT: 0 mB: 0 qB: 0} layer=0x81a085c testkhtml: RenderBody(1): 0x81a08a4 ci mmk zI: auto <body> (0,-1,796,0) [1-1] { mT: -1 qT: 0 mB: 0 qB: 0} testkhtml: RenderTable(1): 0x81a0918 ci mmk zI: auto <table> (0,-500000,0,0) [120-120] { mT: 0 qT: 0 mB: 0 qB: 0} testkhtml: RenderTableSection(1): 0x81a09b4 mmk zI: auto <tbody> (0,0,0,0) [-1--1] { mT: 0 qT: 0 mB: 0 qB: 0} testkhtml: RenderTableRow(1): 0x81a0a10 mmk zI: auto <tr> (0,0,0,0) [0-0] { mT: 0 qT: 0 mB: 0 qB: 0} testkhtml: RenderTableCell(1): 0x81a0a34 mmk zI: auto <td> (0,0,0,0) [1-1] { mT: 0 qT: 0 mB: 0 qB: 0} [r=0 c=0 rs=1 cs=1] testkhtml: RenderBlock (anonymous)(1): 0x81a0ba0 ci an mmk zI: auto (0,-500000,0,0) [1-1] { mT: 0 qT: 0 mB: 0 qB: 0} testkhtml: RenderImage(1): 0x81a0ab8 il rp lt mmk zI: auto <img> (0,0,1,1) [1-1] { mT: 0 qT: 0 mB: 0 qB: 0} testkhtml: RenderBlock(2): 0x81a0b30 ci mmk zI: auto <div> (0,-500000,0,0) [0-0] { mT: 0 qT: 0 mB: 0 qB: 0} testkhtml: RenderInline(1): 0x81a0c10 il ci mmk zI: auto anchor <a> (0,0,0,0) [0-0] { mT: 0 qT: 0 mB: 0 qB: 0} testkhtml: RenderImage(1): 0x81a0c64 il rp lt mmk zI: auto <img> (0,0,0,0) [0-0] { mT: 0 qT: 0 mB: 0 qB: 0} testkhtml: RenderText(2): 0x81a0cdc il mmk zI: auto <text> (0,0,0,15) [0-3] { mT: 0 qT: 0 mB: 0 qB: 0} " " lt-testkhtml: rendering/bidi.cpp:452: khtml::InlineFlowBox* khtml::RenderBlock::createLineBoxes(khtml::RenderObject*): Assertion `obj->isInlineFlow() || obj == this' failed. The anonymous RenderBlock that causes the problem is created in RenderFlow::createAnonymousBlock(), this call is triggered by DOM::DocumentImpl::updateStyleSelector() #0 khtml::RenderFlow::createAnonymousBlock() (this=0x819cb8c) at rendering/render_flow.cpp:314 #1 0x401ded58 in khtml::RenderBlock::makeChildrenNonInline(khtml::RenderObject*) (this=0x819cb8c, insertionPoint=0x0) at rendering/render_block.cpp:308 #2 0x401de4c1 in khtml::RenderBlock::addChildToFlow(khtml::RenderObject*, khtml::RenderObject*) (this=0x819cb8c, newChild=0x819cc88, beforeChild=0x0) at rendering/render_block.cpp:188 #3 0x401f9da2 in khtml::RenderFlow::addChild(khtml::RenderObject*, khtml::RenderObject*) (this=0x819cb8c, newChild=0x819cc88, beforeChild=0x0) at rendering/render_flow.cpp:132 #4 0x4019c528 in DOM::ElementImpl::attach() (this=0x81a3688) at dom_nodeimpl.h:87 #.... #22 0x4018f9eb in DOM::DocumentImpl::updateStyleSelector() (this=0x8198434) at xml/dom_docimpl.cpp:1794
Note also that .boxad is defined in the html (inside the table!!!) as: <style>.boxad { float: none; clear: none;}</style> but in http://www.globeandmail.com/cssv3/net5upcss.css as: .boxad { float: right; clear: both;}
It looks like the style sheet changes the <div id="adSpeed"> to a float. This then makes that RenderBlock::addChildToFlow() moves <img src="small.gif" ...> into an anonymous block (render_block.cpp:187) by calling makeChildrenNonInline And then later we assert because the anonymous block isn't liked by RenderBody (??)
The following gives a similar failure, Credits to coolo for reducing the previous testcase: <style>.boxad { float: right; clear: both;}</style> <table class="boxad"><tr><td> <script type="text/javascript"></script> <img src="http://www.kde.org"> <style>.boxad { float: none; clear: none;}</style> </td></tr></table> The assert is now due to RenderBody complaining about RenderTableCell. There is no anonymous block involved any more.
This bug was marked a duplicate of bug 72775 That bug is still not solved in 3.2RC1 So kmail still crashes when I want to print an email... See attached my xsession_errors generated when trying to print something with kmail.
Created attachment 4261 [details] last part of my xsession-errors generated when kmail crashes .xsession-errors generated when kmail crashes trying to print an email. Probably redundant, but perhaps it helps :-) Thanks for all the hard work!
Another example: http://www.globetechnology.com/servlet/ArticleNews/TPStory/LAC/20040121/SALVATION21/TPTechInvestor/ konqueror: bidi.cpp:445: khtml::InlineFlowBox* khtml::RenderBlock::createLineBoxes(khtml::RenderObject*): Assertion `false' failed. (3.2-RC1 compiled from source)
*** Bug 73169 has been marked as a duplicate of this bug. ***
*** Bug 73407 has been marked as a duplicate of this bug. ***
#73407 got a nice working test case too
*** Bug 74514 has been marked as a duplicate of this bug. ***
*** Bug 74779 has been marked as a duplicate of this bug. ***
*** Bug 75257 has been marked as a duplicate of this bug. ***
*** Bug 75165 has been marked as a duplicate of this bug. ***
*** Bug 75410 has been marked as a duplicate of this bug. ***
*** Bug 75806 has been marked as a duplicate of this bug. ***
*** Bug 75948 has been marked as a duplicate of this bug. ***
*** Bug 77871 has been marked as a duplicate of this bug. ***
Does this bug still exist? Works for me. KDE 3.2.1 from Debian unstable. None of the links cause a crash in my Konqueror and they render perfectly. Clicking locations are fine too.
Yes, I am most definitely still affected by this bug. Usually the front or first page loads, but almost always it seems that clicking on a link will lock Konqueror. I am also using the Debian Sid packages.
ok, but debian sid packages are many many months old..
I'm using a freshly-compiled KDE 3.2.1, and konqueror still hangs every time I click on a link on the www.globeandmail.com homepage. MEF
"Sid" is simply another term for Unstable, which has KDE 3.2.1. Perhaps you're thinking of "Woody", the codename for the last Debian stable release, which shipped with KDE 2.
*** Bug 78584 has been marked as a duplicate of this bug. ***
Debian has formally received a report of this issue as well, bug #243956. I can personally confirm the accuracy of its description of the problem: For about 2 or 3 updates of konqueror or things in KDE which I think might be related, konqueror locks up on attempting to view articles at one particular site (http://www.theglobeandmail.com/) which is a newspaper (The Globe and Mail). The front page loads fine, but if I go to read a story, it downloads some and then locks up. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.18 Locale: LANG=C, LC_CTYPE=C
Confirmed with Gentoo's Konqueror 3.2.1 on x86. Here's a twist (which might explain why links on the pages work for a handful of people): it works fine if I set the User Agent string to pretend to be IE 6.0, but hangs as reported if I let Konqueror be itself. This is probably because the pages use JavaScript to load different CSS depending on the UA string.
Confirming that the hang still occurs with Konqueror 3.2.2 (Gentoo, Athlon XP 32-bit).
confirm that Konqueror 3.2.2 hangs with 100 % CPU when trying to render stories from Globe & Mail. this was also true of 3.2.1 , but 3.2.0 crashed. there are other problems with the Globe & Mail site, suggesting their incompetence: side bars & ads spill over text; clicking links causes sudden jump in position, which may result in going to an unexpected page (link). the latter problems occur with Galeon, but the hang doesn't occur: i can render Globe & Mail stories perfectly well with Galeon 1.3.12 . i have no other problems with Konqueror itself or using it to access other sites. my Gentoo system is very stable. i will also report the problem to the Globe & Mail's site managers, if possible.
i have reported the problem to the Globe & Mail & received a very prompt & positive response: they promise to investigate. there are other problems there, which interfere w easy reading eg via Galeon. i will report back here when there is further progress from G & M.
Philip: Any chance you can grab a good testcase and attach it to this bug report _before_ the Globe corrects their site? It's nice to try to fix the problem on the Globe's end, but Konqueror should be able to keep working no matter how twisted the HTML/CSS/EcmaScript is. I can guarantee that the Globe isn't the only site creating horrible Web code -- so if they fix their code, we'll just run into similar problems with Konqueror on smaller Web sites with "creative" HTML.
*** Bug 81945 has been marked as a duplicate of this bug. ***
I can get this the main page loads fine but when I click on a link to a story it *USUALLY* crashes. Sometimes it will load the story; but then if I go back (by way of the Back button or "Alt + <-", then main page renders fine, but then the next link will crash it. This will also happen if I get the link to a story on G&M from news.google.ca or something like that and follow it. It seems to work correctly with both IE and Firefox. I started a thread here http://justlinux.com/forum/showthread.php?s=&threadid=128220 on it.
*** Bug 84255 has been marked as a duplicate of this bug. ***
I'm also having this problem with links I follow from the main page of the Globe and Mail site, news stories that is. Turning off JavaScript fully resolves the problem and interestingly (though I have no idea why) turning off the plugins globally allows the headline of the story to display but then it freezes before the entire article does. This is the article that was testing with: http://globeandmail.com/servlet/story/RTGAM.20040702.w2iraq0702/BNStory/International/ I'm using the SuSE 9.1 RPMs. I don't know enough or have enough time to compile it form source or test development versions but if there's any other way I can help, ask away. Not getting any error messages even when Konqueror is run from the terminal (or anything for that matter).
KDE 3.3 beta2 still crashes via this link http://news.google.com/url?ntc=0Md&q=http://www.theglobeandmail.com/servlet/ArticleNews/TPStory/LAC/20040727/RGOO27/TPBusiness/MoneyMarkets
Bug still exists in KDE 3.3.0beta2. See here for instance: http://www.theglobeandmail.com/servlet/ArticleNews/TPStory/LAC/20040724/ROBOT24/ (Linked from /. just today. No good marketing for us, that.) * Reproducible: Not always. Reloading the page eventually yields a crash, though. * Traceback follows: Using host libthread_db library "/lib/libthread_db.so.1". [KCrash handler] #5 0xb645cd98 in khtml::RenderBlock::createLineBoxes(khtml::RenderObject*) () from /usr/kde/3.3/lib/libkhtml.so.4 #6 0xb645cdc1 in khtml::RenderBlock::createLineBoxes(khtml::RenderObject*) () from /usr/kde/3.3/lib/libkhtml.so.4 #7 0xb645cdc1 in khtml::RenderBlock::createLineBoxes(khtml::RenderObject*) () from /usr/kde/3.3/lib/libkhtml.so.4 #8 0xb645ceb9 in khtml::RenderBlock::constructLine(khtml::BidiIterator const&, khtml::BidiIterator const&) () from /usr/kde/3.3/lib/libkhtml.so.4 #9 0xb645e8e7 in khtml::RenderBlock::layoutInlineChildren(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #10 0xb6461223 in khtml::RenderBlock::layoutBlock(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #11 0xb648761b in khtml::RenderTableCell::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #12 0xb6487322 in khtml::RenderTableRow::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #13 0xb6472557 in khtml::RenderContainer::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #14 0xb6482a8b in khtml::RenderTable::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #15 0xb6463588 in khtml::RenderBlock::insertFloatingObject(khtml::RenderObject*) () from /usr/kde/3.3/lib/libkhtml.so.4 #16 0xb64627c4 in khtml::RenderBlock::layoutBlockChildren(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #17 0xb6461490 in khtml::RenderBlock::layoutBlock(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #18 0xb648761b in khtml::RenderTableCell::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #19 0xb6487322 in khtml::RenderTableRow::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #20 0xb6472557 in khtml::RenderContainer::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #21 0xb6482a8b in khtml::RenderTable::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #22 0xb64623ff in khtml::RenderBlock::layoutBlockChildren(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #23 0xb6461490 in khtml::RenderBlock::layoutBlock(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #24 0xb6461093 in khtml::RenderBlock::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #25 0xb64623ff in khtml::RenderBlock::layoutBlockChildren(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #26 0xb6461490 in khtml::RenderBlock::layoutBlock(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #27 0xb6461093 in khtml::RenderBlock::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #28 0xb64623ff in khtml::RenderBlock::layoutBlockChildren(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #29 0xb6461490 in khtml::RenderBlock::layoutBlock(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #30 0xb648761b in khtml::RenderTableCell::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #31 0xb6487322 in khtml::RenderTableRow::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #32 0xb6472557 in khtml::RenderContainer::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #33 0xb6482a8b in khtml::RenderTable::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #34 0xb64623ff in khtml::RenderBlock::layoutBlockChildren(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #35 0xb6461490 in khtml::RenderBlock::layoutBlock(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #36 0xb6461093 in khtml::RenderBlock::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #37 0xb64623ff in khtml::RenderBlock::layoutBlockChildren(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #38 0xb6461490 in khtml::RenderBlock::layoutBlock(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #39 0xb6461093 in khtml::RenderBlock::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #40 0xb64623ff in khtml::RenderBlock::layoutBlockChildren(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #41 0xb6461490 in khtml::RenderBlock::layoutBlock(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #42 0xb6461093 in khtml::RenderBlock::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #43 0xb64623ff in khtml::RenderBlock::layoutBlockChildren(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #44 0xb6461490 in khtml::RenderBlock::layoutBlock(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #45 0xb6461093 in khtml::RenderBlock::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #46 0xb64a4031 in khtml::RenderBody::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #47 0xb64623ff in khtml::RenderBlock::layoutBlockChildren(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #48 0xb6461490 in khtml::RenderBlock::layoutBlock(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #49 0xb6461093 in khtml::RenderBlock::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #50 0xb64623ff in khtml::RenderBlock::layoutBlockChildren(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #51 0xb6461490 in khtml::RenderBlock::layoutBlock(bool) () from /usr/kde/3.3/lib/libkhtml.so.4 #52 0xb6461093 in khtml::RenderBlock::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #53 0xb649d41d in khtml::RenderCanvas::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #54 0xb63b2791 in KHTMLView::layout() () from /usr/kde/3.3/lib/libkhtml.so.4 #55 0xb63ba2d2 in KHTMLView::timerEvent(QTimerEvent*) () from /usr/kde/3.3/lib/libkhtml.so.4 #56 0xb7273c23 in QObject::event(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #57 0xb72ac2ef in QWidget::event(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #58 0xb721a45f in QApplication::internalNotify(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #59 0xb721981e in QApplication::notify(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #60 0xb7853a0a in KApplication::notify(QObject*, QEvent*) () from /usr/kde/3.3/lib/libkdecore.so.4 #61 0xb7209b95 in QEventLoop::activateTimers() () from /usr/qt/3/lib/libqt-mt.so.3 #62 0xb71c3d8b in QEventLoop::processEvents(unsigned) () from /usr/qt/3/lib/libqt-mt.so.3 #63 0xb722c5d8 in QEventLoop::enterLoop() () from /usr/qt/3/lib/libqt-mt.so.3 #64 0xb722c488 in QEventLoop::exec() () from /usr/qt/3/lib/libqt-mt.so.3 #65 0xb721a6b1 in QApplication::exec() () from /usr/qt/3/lib/libqt-mt.so.3 #66 0xb684141c in kdemain () from /usr/kde/3.3/lib/libkdeinit_konqueror.so #67 0xb7777982 in kdeinitmain () from /usr/kde/3.3/lib/kde3/konqueror.so #68 0x0804d074 in launch(int, char const*, char const*, char const*, int, char const*, bool, char const*, bool, char const*) () #69 0x0804e716 in handle_launcher_request(int) () #70 0x0804ec98 in handle_requests(int) () #71 0x0804feb9 in main () Traceback is static across crashes. Anything else I can do to help?
I had the same link tested in Safari v 1.1, MacOS X 10.3.4, WebCore 1.2.2 BuildVersion 24, SourceVersion 1250604. It works fine -- no crash, even after a number of reloads. Apparently this bug is somehow fixed in the Apple codebase.
I compiled CVS HEAD on my Gentoo system with sources from 01.sep.2004. I've done all what as been described above here to chrash konquerer (duplicates not included). No crash :-) Is this now stable for others too? Cheers Jo
Initially looked OK but after following a few links it crashed.
CVS commit by ggarand: Check soundness of parent's flow structure with regard to the child's display when the latter changes. Adapted from WebCore. Fixes globeandmail.com family of crashes. BUG: 65715 M +19 -0 ChangeLog 1.331 M +48 -0 rendering/render_box.cpp 1.246 M +6 -1 rendering/render_box.h 1.81 M +0 -13 rendering/render_flow.cpp 1.357 M +0 -2 rendering/render_flow.h 1.94 M +2 -2 rendering/render_inline.cpp 1.15 M +6 -6 rendering/render_inline.h 1.11 M +4 -10 rendering/render_line.cpp 1.18 M +1 -2 rendering/render_object.cpp 1.272
On Tuesday 09 November 2004 08:26, Germain Garand wrote: > > Check soundness of parent's flow structure with regard to > the child's display when the latter changes. Adapted from WebCore. > > Fixes globeandmail.com family of crashes. WOW! Nice!
*** Bug 98764 has been marked as a duplicate of this bug. ***