CLOSED FIXED Bug 10318
[S60] Reindeer crashes when started
https://bugs.webkit.org/show_bug.cgi?id=10318
Summary [S60] Reindeer crashes when started
Kari Pihkala
Reported 2006-08-09 03:34:16 PDT
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.
Attachments
Kari Pihkala
Comment 1 2006-08-09 04:42:08 PDT
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
Comment 2 2006-08-09 12:21:46 PDT
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
Comment 3 2006-08-09 20:03:25 PDT
Kari Pihkala
Comment 4 2006-08-10 00:54:51 PDT
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
Comment 5 2006-08-10 17:00:48 PDT
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
Comment 6 2006-08-11 03:44:23 PDT
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
Comment 7 2006-08-11 07:43:27 PDT
(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
Comment 8 2006-08-11 07:45:34 PDT
Verified on the Webkit at r15828. Reindeer no loger crashes when launched. Closed.
Bradley Morrison
Comment 9 2006-08-16 14:46:24 PDT
Note that r15916 specifically removes support for SDK MR release from the build script.
Victor Wang
Comment 10 2010-12-02 16:16:16 PST
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
Comment 11 2010-12-02 16:17:18 PST
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?
Note You need to log in before you can comment on or make changes to this bug.