Bug 90008 - [Qt] Assertion reached when accessing mainFrame()->setHTML(""); from QWebPage
Summary: [Qt] Assertion reached when accessing mainFrame()->setHTML(""); from QWebPage
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Qt (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Major
Assignee: Nobody
Depends on:
Reported: 2012-06-26 13:21 PDT by Viv Rajkumar
Modified: 2014-01-13 21:46 PST (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Viv Rajkumar 2012-06-26 13:21:05 PDT

Qt Version: 4.8.2
My Machine: Windows 7 (x86)
Build Type: Release
Compiler: Visual Studio 2012 RC

Problem currently is QtWebKit4.dll crashes *ONLY* in x86 Release mode (Have tested Debug and x64 both types) on calling mainFrame()->setHtml("anything") from inside a subclassed QWebPage constructor.

Have noticed this problem presents itself also on QT-WebKit examples like "previewer", "domtraversal" again only in release mode.

I built the debugging symbols for Release QtWebKit4.dll to identify the origin of this error and found it at:

File: TextEncodingRegistry.cpp (Line 333) 

PassOwnPtr<TextCodec> newTextCodec(const TextEncoding& encoding)
  return factory.function(encoding, factory.additionalData);

In factory.functor assertion is triggered even though just above it there is an assert making sure it's not invalid (I'm not able to step any further into the code to debug it)

Call-Stack I got from Visual Studio:

>	QtWebKit4.dll!WebCore::newTextCodec(const WebCore::TextEncoding & encoding)  Line 333 + 0x24 bytes	C++
 	QtWebKit4.dll!WebCore::TextResourceDecoder::flush()  Line 685 + 0xd bytes	C++
 	QtWebKit4.dll!WebCore::DecodedDataDocumentParser::appendBytes(WebCore::DocumentWriter * writer, const char * data, int length, bool shouldFlush)  Line 48 + 0xb bytes	C++
 	QtWebKit4.dll!WebCore::DocumentWriter::endIfNotLoadingMainResource()  Line 229	C++
 	QtWebKit4.dll!WebCore::FrameLoader::init()  Line 239	C++
 	QtWebKit4.dll!QWebFrame::QWebFrame(QWebPage * parent, QWebFrameData * frameData)  Line 540	C++
 	QtWebKit4.dll!QWebPagePrivate::createMainFrame()  Line 426 + 0x23 bytes	C++
 	QtWebKit4.dll!QWebPage::mainFrame()  Line 2003	C++

To Reproduce Problem:
1.a. Either just call setHtml() on QWebView or QWebPage()->mainFrame() from release in the current build environment.
1.b. QT-Examples "previewer", "domtraversal" also have this problem in release.

Possible WorkAround:
1. Have been trying to find a workaround currently until an offical fix is available by trying to set the QWebPage's defaultTextCodec() from code before setHtml() is called. That does not work though, the if condition still fails and goes to the newTextCodec function

Thank you,

Comment 1 Viv Rajkumar 2012-07-01 16:10:43 PDT
Seems to be a problem with the ->get() function of HashMap.h & MSVC 2012

Does not seem to like key's with an uppercase character as the first character.

Managed to fix it by avoiding the get() function in TextEncodingRegistry.cpp


static void addToTextCodecMap(const char* name, NewTextCodecFunction function, const void* additionalData)


const char* atomicName = textEncodingNameMap->get(name);


const char* atomicName;
TextEncodingNameMap::iterator pos;
for (pos = textEncodingNameMap->begin(); pos != textEncodingNameMap->end(); ++pos) {
  if (strcmp(pos->first, name) == 0) {
    atomicName = pos->second;

And In:

PassOwnPtr<TextCodec> newTextCodec(const TextEncoding& encoding)


TextCodecFactory factory = textCodecMap->get(encoding.name());


TextCodecFactory factory;
TextCodecMap::iterator pos;
for (pos = textCodecMap->begin(); pos != textCodecMap->end(); ++pos) {
  if (strcmp(pos->first, encoding.name()) == 0) {
    factory = pos->second;
Comment 2 Jeff 2013-03-21 05:59:08 PDT
I can confirm that this is still a problem On Windows 7 VS2012 Release build.

It appears that atomicCanonicalTextEncodingName is executing when an access violation occurs, due to deref'ing a null pointer. Several related 'this' pointers have become null. 

The code is difficult to debug with /O2 optimizations, as lots of code is relocated, particularly mutex locking. So I built with /O1 and lo-and-behold no access violations. I also tried /Ox which but this gives the same result as /O2.

So a workaround is to compile WebCore with /O1 optimization flag.