Bug 10318 – [S60] Reindeer crashes when started

• Component: Accessibility
• Status: CLOSED FIXED

[Kari Pihkala]

Working with Maintenance Release SDK from forum.nokia and Reindeer svn revision 15822 (checked out 9-Aug-06). It builds fine, but when Reindeer is launched (under Installations) it crashes immediately. 

I debugged it and it crashes on this call in S60/WebKit/BrowserView/src/LoadListeners.cpp, line 165, method CPageLoadListener::HeadersL()

...
    // set response url
    iWebKitLoader->SetPageUrlL( headerInfo.ResponseUrl() );

    // create new document only if
    if( headerInfo.HttpStatus() == EHttpOK )
        {
        // Since the new page is loading fine, we should update the position of history
        // the history list
CRASHES>> iWebKitLoader->WebKitBridge().Frame().WebKitView().WebKitControl().HistoryController().UpdateCurrentEntryPosition();

        //Reset all the flags in webkitview, do this only once
        if (!iWebKitLoader->WebKitBridge().Frame().Parent())
            {
            iWebKitLoader->WebKitBridge().Frame().WebKitView().ResetFlags();
            }

Here's the stack trace:

19 CWebKitView::MainFrame() at WebKitView.h:453
18 CHistoryController::UpdateCurrentEntryPosition() at HistoryController.cpp:603
17 CPageLoadListener::HeadersL() at LoadListeners.cpp:168
16 CContentDispatcher::HeadersL() at ContentDispatcher.cpp:298
15 CUrlLoader::HeadersL() at UrlLoader.cpp:233
14 CFileTransaction::MHFRunL() at FileTransaction.cpp:321
13 CFileReader::RunL() at FileReader.cpp:197
12 0x600028AF( euser.dll )() 
11 0x6000269A( euser.dll )() 
10 0x600024FA( euser.dll )() 
9 0x600023BB( euser.dll )() 
8 0x4061146F( CONE.DLL )() 
7 0x40B5E8C5( eikcore.dll )() 
6 0x40B5E5AC( eikcore.dll )() 
5 E32Main() at WebUiApp.cpp:122
4 _E32Startup() at uc_exe.cpp:46
3 0x83A9FD( ekern.exe )() 
2 0x838DA2( ekern.exe )() 
1 0x7C80B50B( KERNEL32.dll )() 

If I comment the crashing line out, it crashes at another location. I can prevent the second crash by commenting out the following line in S60/S60WebUi/WebUi/src/WebUiWindow.cpp (line 190, this loads the homepage).

TInt CWebUiWindow::SubmitCallbackL( TAny* aAny )
    {
    CWebUiWindow* thisObj = (CWebUiWindow*)aAny;
    thisObj->CancelSubmitTimer();
    //Commented out>> thisObj->DoSubmitL();

    return KErrNone;
    }

The result is a blank page, i.e. the homepage does not display. The great thing is that the browser starts and I can then open any local document, and it displays fine. Also, I have been able to run some layout tests.

I haven't been able to debug CHistoryController as it is closed source.

[Kari Pihkala]

I did a bit more investigations..

The second crash actually happens in CWebKitBridge::UserAgentForURL(). The line 190 at SubmitCallbackL() doesn't need to be commented out if the line 326 (webkitbridge.cpp) is modified as follows.

TPtrC CWebKitBridge::UserAgentForURL(
    const TDesC& /*aURL*/ )
    {
OLD>>  //return iFrame->WebKitView().WebKitControl().UserAgentStringL();
NEW>>  return _L("Reindeer");
    }

As a result, the homepage loads now fine after startup. Also, all web pages, such as www.google.com work now (web pages didn't work before this, only local pages).

So, in addition to HistoryController, it seems that there is something wrong with the method UserAgentStringL(). 

I'm only posting the code changes so that you can see what makes the browser work - I know they are NOT real bug fixes.

[Bradley Morrison]

Hi Kari,

I can confirm this, setting to new. 

In reply to comment #1)
> I did a bit more investigations..

Thanks, appreciate your investigation! 

> I'm only posting the code changes so that you can see what makes the browser
> work - I know they are NOT real bug fixes.

Sure, it's a great help nevertheless. We will investigate this ASAP.

Thanks for the feedback,
Bradley

[zalan]

r15827

[Kari Pihkala]

I checked out rev. 15828 (seems to be the same as 15827), but Reindeer still crashes during startup for me (KERN-EXEC 3).

Looks like HistoryController works now ok, thx for that! However, the second issue (UserAgentStringL) is still causing the browser to crash.

Here's the stack trace:

46 0x839271( ekern.exe )() 
45 CBrowserSettingsContainer::SettingL() at BrowserSettingsContainer.cpp:133
44 0x60004FF5( euser.dll )() 
43 0x249B18DC( webutils.dll )() 
42 0x249B2A2D( webutils.dll )() 
41 0x249B25F6( webutils.dll )() 
40 0x249B1A87( webutils.dll )() 
39 CWebKitControl::UserAgentStringL() at WebKitControl.cpp:1211
38 CWebKitBridge::UserAgentForURL() at WebKitBridge.cpp:326
37 KWQKHTMLPart::userAgent() at KWQKHTMLPart.cpp:1241
36 KJSProxyImpl::initScript() at kjs_proxy.cpp:284
35 KJSProxyImpl::createHTMLEventHandler() at kjs_proxy.cpp:167
34 KHTMLPart::createHTMLEventListener() at khtml_part.cpp:5512
33 DOM::DocumentImpl::createHTMLEventListener() at dom_docimpl.cpp:2971
32 DOM::HTMLElementImpl::parseHTMLAttribute() at html_elementimpl.cpp:445
31 DOM::HTMLGenericFormElementImpl::parseHTMLAttribute() at html_formimpl.cpp:827
30 DOM::HTMLInputElementImpl::parseHTMLAttribute() at html_formimpl.cpp:1771
29 DOM::HTMLElementImpl::attributeChanged() at html_elementimpl.cpp:357
28 DOM::ElementImpl::setAttributeMap() at dom_elementimpl.cpp:359
27 KHTMLParser::parseToken() at htmlparser.cpp:251
26 khtml::HTMLTokenizer::processToken() at htmltokenizer.cpp:2042
25 khtml::HTMLTokenizer::parseTag() at htmltokenizer.cpp:1448
24 khtml::HTMLTokenizer::write() at htmltokenizer.cpp:1715
23 KHTMLPart::write() at khtml_part.cpp:1760
22 KWQKHTMLPart::addData() at KWQKHTMLPart.cpp:811
21 CWebCoreBridge::AddData() at WebCoreBridge.cpp:310
20 CPageLoadListener::ResponseL() at LoadListeners.cpp:284
19 CContentDispatcher::ResponseL() at ContentDispatcher.cpp:343
18 CUrlLoader::ResponseL() at UrlLoader.cpp:247
17 CBaseTransaction::RunL() at BaseTransaction.cpp:363
16 CBaseTransaction::SendPartialResponse() at BaseTransaction.cpp:402
15 CBaseTransaction::AddBodyDataL() at BaseTransaction.cpp:506
14 CFileTransaction::MHFRunL() at FileTransaction.cpp:330
13 CFileReader::RunL() at FileReader.cpp:197
12 0x600028AF( euser.dll )() 
11 0x6000269A( euser.dll )() 
10 0x600024FA( euser.dll )() 
9 0x600023BB( euser.dll )() 
8 0x4061146F( CONE.DLL )() 
7 0x40B5E8C5( eikcore.dll )() 
6 0x40B5E5AC( eikcore.dll )() 
5 E32Main() at WebUiApp.cpp:122
4 _E32Startup() at uc_exe.cpp:46
3 0x83A9FD( ekern.exe )() 
2 0x838DA2( ekern.exe )() 
1 0x7C80B50B( KERNEL32.dll )() 

The browser starts up fine if I do the code change in comment #1.

[Bradley Morrison]

Hmm, others have confirmed that the fix has stabilised reindeer. 

This sounds like another binary incompatability issue that others are not seeing. I saw bug 10330, are you using the maintenance release version SDK by any chance? I'm not sure if that will work just at the moment - we are using just the 3rd edition. The contents of S60Libs.zip would likely need to be updated to match the other libs in the later version of the SDK.  Is it possible for  you to try against SDK 3rd edition? It might take a little bit of time for us to support any version of the SDK.

[Kari Pihkala]

True, I'm was using S60 3rd Edition Maintenance Release SDK. 

I tried running Reindeer with S60 3rd Edition SDK, and it runs flawlessly. The UserAgentString problem doesn't occur with it.

[Krishna]

(In reply to comment #6)
> True, I'm was using S60 3rd Edition Maintenance Release SDK. 
> I tried running Reindeer with S60 3rd Edition SDK, and it runs flawlessly. The
> UserAgentString problem doesn't occur with it.

This error should be closed as this was not reproducible on the supported S60 3rd Edition SDK.

[Krishna]

Verified on the Webkit at r15828. Reindeer no loger crashes when launched.

Closed.

[Bradley Morrison]

Note that r15916 specifically removes support for SDK MR release from the build script. 

[Victor Wang]

This test is currently disabled for win and linux, and there is a bug that track it: http://code.google.com/p/chromium/issues/detail?id=10318

Maybe we should just disable it on mac instead of rebaseline?

[Victor Wang]

Sorry, I did not mean to comment on this bug. ignore comment#10.

(In reply to comment #10)
> This test is currently disabled for win and linux, and there is a bug that track it: http://code.google.com/p/chromium/issues/detail?id=10318
> 
> Maybe we should just disable it on mac instead of rebaseline?