#10924 closed bug (fixed)
Webpositive crashed WebCore::ResourceHandle::client()
Reported by: | xray7224 | Owned by: | pulkomandy |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Applications/WebPositive | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | #11602 | Blocking: | #12047, #12137, #12605, #13523 |
Platform: | All |
Description
Web positive crashed. I wasn't doing anything specific just browsing around the web.
I'm using hrev47328 Web positive version: 1.1-alpha HaikuWebKit: 1.3.1 WebKit: 538.33
Attachments (6)
Change History (33)
by , 10 years ago
Attachment: | WebPositive-878-debug-08-06-2014-19-29-45.report added |
---|
by , 10 years ago
Attachment: | WebPositive-17341-debug-10-12-2014-08-59-45.report added |
---|
crash in hrev48472
comment:3 by , 10 years ago
This is happening on hrev48819 with haikuwebkit-1.4.10.
To reproduce, go to https://gerrit.libreoffice.org/ and click on the login link on the top right. Will crash every time.
by , 10 years ago
Attachment: | WebPositive-904-debug-24-02-2015-07-20-27.report added |
---|
Up to date debug report
comment:5 by , 9 years ago
Blocking: | 12137 added |
---|
comment:6 by , 9 years ago
Blocking: | 12605 added |
---|
comment:7 by , 9 years ago
Blocked By: | 11602 added |
---|
by , 9 years ago
Attachment: | 0001-Get-client-right-after-check-for-valid-resourcehandl.patch added |
---|
Fix for crash in WebCore::ResourceHandle::client
comment:8 by , 9 years ago
patch: | 0 → 1 |
---|
comment:9 by , 9 years ago
I thought I had fixed it with the patch attached to #12605, but apparently the variable m_resourceHandle can become null in the function HeadersReceived. I now added a patch that moves retrieving the client to right after checking for a valid resourcehandle. This fixes the crash, but I'm not sure why the m_resourceHandle variable becomes null in the function itself.
comment:10 by , 9 years ago
HeadersReceived is called from the request's own thread. While the request is running, WebKit can decide to abort it. When it does that, it resets the pointer, so the requests crashes (cleanly) instead of corrupting memory. When such crashes happen, moving the things around is not the right thing to do. Instead, the problem should be investigated, and locking added in the right places to avoid such problems.
A big part of the network code in WebKit could be cleaned up. It was derived from the curl code then grew over the years to accomodate changes in our API. I think the whole thing should be reviewed for locking issues.
comment:11 by , 9 years ago
I understand moving things around is not the solution, but doing a review for the whole thing is going to take quite a bit of time I expect, while this crashing issue remains. I would rather have it not crash, while the review is going on.
I would like to look into the locking problem, though. Could you explain how the network code works? Which threads are running and what kind of calls are made to the Haiku networking code? This ticket may not be the right place for it, though.
comment:12 by , 9 years ago
I did some quick debugging to see what is going wrong and it does not seem to be a locking problem. In this case AuthenticationNeeded is called from HeadersReceived and it determines that it is an unknown authentication type and should be ignored. It then calls client->didFinishLoading() and returns. Apparently the call to client->didFinishLoading() destroys the ResourceHandle somewhere, which unsets m_resourceHandle. This then causes the call to m_resourceHandle->client() to fail. Checking if m_resourceHandle is still valid right before this call should fix it. Again, not sure if it is the right fix.
comment:13 by , 9 years ago
That sounds like an error in AuthenticationNeeded. Unknown authentication types should be passed as-is to the web page and not interrupt the request. Javascript code can then access the HTTP headers and process the authentication request.
As for the services kit design:
Each HTTP request (BHttpRequest) runs in its own thread. It notifies an UrlProtocolListener of all events. In the case of WebKit, an UrlProtocolDispatchingListener is used, which relays the messages to an UrlProtocolAsynchronousListener running in the main thread. This serializes the events so there shouldn't be too much locking problems in this case.
There are some exceptions:
- Some XmlHttpRequests are handled synchronously, which means the main thread is blocked waiting for them to complete. This may cause some of the freezes we get.
- WebSockets are handled with separate code in the WebKit repo, with even more threads (2 per sockets IIRC), and is known to be broken in several cases.
comment:14 by , 9 years ago
Disabling the client->didFinishLoading call when an unknown authentication is encountered fixes the crash and shows me the OpenID login screen for https://gerrit.libreoffice.org/, so that looks positive.
Is this always a good idea? What if AuthenticationNeeded is called from somewhere else than HeadersReceived?
comment:15 by , 9 years ago
I don't think it will be called from elsewhere. Only the HTTP authentication header can trigger it.
by , 9 years ago
Attachment: | 0001-Don-t-finish-loading-when-unknown-authentication-typ.patch added |
---|
Fix for handling of unknown authentication type
comment:16 by , 9 years ago
I added a patch that removes the client->didFinishLoading call when an unknown authentication type is encountered. I do wonder about the other calls to didFinishLoading in that function, though. Are they wrong as well?
comment:17 by , 9 years ago
The idea for the other authentication types was to cancel the request, and avoid downloading the "authentication needed" page content, knowing that the user would request the page again (with authentication data). This is probably not needed anymore, but at least it does not seem to trigger a crash? Or is there some ticket about that too?
comment:18 by , 9 years ago
What I mean is that there are two other places in AuthenticationNeeded that call client->didFinishLoading:
- if m_redirectionTries == 0
- if d->m_user == ""
How bad is that? I am not aware of any issues that relate to those two calls, but if they are triggered it seems to me that this will cause the same kind of crash as we have in this instance.
comment:19 by , 9 years ago
These two case are supposed to stop the request: The first happens if the browser seems stuck in a redirect loop, The second happens if the user press "cancel" in the HTTP authentication dialog.
In either case, the request should be stopped and not continued with fetching the body. However, the remaining parts of the code should handle this properly, just calling didFinishLoading is not enough as the thread will continue to run for some time.
comment:20 by , 9 years ago
If I understand it correctly, then we still need to check if we want to stop processing after AuthenticationNeeded returns. We could change the following:
if (statusCode == 401) AuthenticationNeeded(httpRequest, response);
into
if (statusCode == 401) { AuthenticationNeeded(httpRequest, response); if (!m_resourceHandle) return; }
comment:21 by , 9 years ago
Yes, that looks like it could work. Maybe with a comment to explain why the resourceHandle can disappear this way?
follow-up: 23 comment:22 by , 9 years ago
I tried to make a patch for that, but wanted to test it first. When I now try to compile HaikuLauncher it errors out with:
[2/26] Linking CXX shared library lib/libWebKit.so.1.5.2 FAILED: : && /bin/g++-x86 -fPIC -march=i686 -std=c++11 -O3 -DNDEBUG -fno-exceptions -fno-strict-aliasing -fno-rtti -frtti -Wl,--no-undefined -shared -Wl,-soname,libWebKit.so.1 -o lib/libWebKit.so.1.5.2 @CMakeFiles/WebKit.rsp && : lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/haiku/RenderThemeHaiku.cpp.o: In function `WebCore::RenderThemeHaiku::paintSliderTrack(WebCore::RenderObject const&, WebCore::PaintInfo const&, WebCore::IntRect const&)': RenderThemeHaiku.cpp:(.text+0x1149): undefined reference to `WebCore::RenderObject::style() const' lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/haiku/RenderThemeHaiku.cpp.o: In function `WebCore::RenderThemeHaiku::paintSliderThumb(WebCore::RenderObject const&, WebCore::PaintInfo const&, WebCore::IntRect const&)': RenderThemeHaiku.cpp:(.text+0x1293): undefined reference to `WebCore::RenderObject::style() const' collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed.
What could be the cause of that?
comment:23 by , 9 years ago
Replying to markh:
I tried to make a patch for that, but wanted to test it first. When I now try to compile HaikuLauncher it errors out with:
[2/26] Linking CXX shared library lib/libWebKit.so.1.5.2 FAILED: : && /bin/g++-x86 -fPIC -march=i686 -std=c++11 -O3 -DNDEBUG -fno-exceptions -fno-strict-aliasing -fno-rtti -frtti -Wl,--no-undefined -shared -Wl,-soname,libWebKit.so.1 -o lib/libWebKit.so.1.5.2 @CMakeFiles/WebKit.rsp && : lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/haiku/RenderThemeHaiku.cpp.o: In function `WebCore::RenderThemeHaiku::paintSliderTrack(WebCore::RenderObject const&, WebCore::PaintInfo const&, WebCore::IntRect const&)': RenderThemeHaiku.cpp:(.text+0x1149): undefined reference to `WebCore::RenderObject::style() const' lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/haiku/RenderThemeHaiku.cpp.o: In function `WebCore::RenderThemeHaiku::paintSliderThumb(WebCore::RenderObject const&, WebCore::PaintInfo const&, WebCore::IntRect const&)': RenderThemeHaiku.cpp:(.text+0x1293): undefined reference to `WebCore::RenderObject::style() const' collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed.What could be the cause of that?
I recently tried to build haikuwebkit too, and also ran into the same error. I've upgraded my system to gcc5, and am wondering if this is the issue?
comment:24 by , 9 years ago
Most likely yes, I pushed a fix to the webkit repo for this build problem.
by , 9 years ago
Attachment: | 0001-Check-if-AuthenticationNeeded-aborted-the-request-be.patch added |
---|
comment:25 by , 9 years ago
Thank, that fixed it. I tested my patch and it seems to be fine. It has a comment indicating why we are checking m_resourceHandle again.
comment:26 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:27 by , 7 years ago
Blocking: | 13523 added |
---|
debug file