[webkit-dev] Crash on start up in Series 60 emulator

bradley.morrison at nokia.com bradley.morrison at nokia.com
Wed Aug 16 14:53:22 PDT 2006

Hi Brad,

This sounds similar to:


But this is the first I've heard of it as at the current S60 trunk,
all clean builds and stable here. We did see something similar
last week, but that was fixed in r15827 (see bug history above).

Please let us know your current SDK version - the latest maintenance
release is not yet supported; I patched the build script and wiki 
recently for that.

If it still crashes after another 'svn up' to the very latest 
and full build on SDK 3.0, is it possible to send us a stack trace?



From: webkit-dev-bounces at opendarwin.org
[mailto:webkit-dev-bounces at opendarwin.org] On Behalf Of ext Brad Lassey
Sent: Wednesday, August 16, 2006 4:51 PM
To: webkit-dev at opendarwin.org
Subject: [webkit-dev] Crash on start up in Series 60 emulator

I had a working build of Webkit for Series 60, then I updated my tree.
Now I get a KERM-EXEC 3 panic on start up.  According to the stack trace
it happens on line 141 of BrowserSettingsContainer.cpp, in the SettingL
method.  I've included that source below

MBrCtlSettingInterface& CBrowserSettingsContainer::SettingL(
TBrCtlDefs::TBrCtlSettings aId )
    TInt settingNum = 0;
    TBool found = EFalse;
    while(( settingNum < iSettings.Count() ) && !found )
        if( aId == (iSettings[settingNum])->SettingId() )  //crash
happens when evaluating here
            found = ETrue;
    // if not found above, then create a new one
    if( !found )
        iSettings.Append( CBrowserSetting::NewL(aId, this) );
        MarkAsUpdatedL( aId );
    return *iSettings[settingNum];

At the time of the crash, settingNum is 0.  I put a breakpoint just
above.  This method is executed just fine several times, being called
from InsertDefaultSettingsL.  The crash happens when it is called during
the construction of a CUserAgent in CWebKitControl::UserAgentStringL.
The peculur thing is that the iCount of the RArray iSettings is
597717828 just before the crash occurs, which seems abnormally high.
Also, it seems that accessing that array at all will cause the crash.

I have now rebuilt from a fresh pull on a fresh computer with the same
results.  Has anyone else seen this behavior?  Is there a fix?


More information about the webkit-dev mailing list