The test browser crashes when loading http://www.wikipedia.org/ I suspect this has to do with complex text support.
Created attachment 16787 [details] backtrace of crash from recent webkit Attached is a backtrace of the crash from recent webkit
It seems it crashes when calling to the delete standard C++ function. This is a weird error since, tracking the problem, we have downloaded the Wikipedia home page to the local harddisk. Opening the page with: file://path_to/Wikipedia.html The page renders perfectly with no errors. We've uploaded the same Wikipedia.html (without images) to another webserver and the page keeps crashing. Also, it keeps crashing without having the images available. We have made some more tests: removing the javascript code -> it keeps crashing, trying to remove the problematic text in the page -> there is no problematic text, since when you remove some amount of content, the page doesn't crashes anymore but, adding the removed text and removing the kept text leads to a non crashing page too. Debugging the page while loading: as shown in the page, it crashes when calling #44 0xb78346cf in WebCore::GlyphPageTreeNode::initializePage (this=0x83e8560, fontData=0x813c528, pageNumber=259) at ../../../WebCore/platform/GlyphPageTreeNode.cpp:150 when trying to defer the GlyphPage object. When loading the page locally, we don't call WebCore::GlyphPageTreeNode::initializePage with pageNumber set to 259 ever. It seems a quite weird problem and, since it doesn't happen locally nor with the Qt port, we think the problem could be in the used network backend in GTK+ port -> libcurl.
Thanks for the sleuth worth so far. To make things more interesting, wikipedia.com does not crash when I use Pango for text rendering instead of the old code path. (Pango patch is not yet released.) Pango won't be the default font engine so this bug still matters.
Preliminary Pango patch released in an attachment to #15610 wikipedia.com loads with that patch applied. It uses Pango for all text though, which is not what we want by default.
*** This bug has been marked as a duplicate of 16054 ***