Crash when loading
Status: Pre-Alpha
Brought to you by:
kollivier
Menu
▾
▴
Logged In: YES
user_id=248468
Originator: NO
I've been able to figure out that this problem is Windows-specific, but the crash involves threads, so the debug traceback isn't very helpful. I'll try and see if there are any fixes to the CURL loader code that haven't yet been backported from WebKit TOT to wxWebKit, but this may take time to debug.
As for the image issues, I'm only seeing them on Windows right now, although I'm experimenting with a wxGraphicsContext-based implementation on Linux, so it's possible that wxGraphicsContext fixes the issue... I'll let you know when I learn more about these problems.
Logged In: YES
user_id=1558272
Originator: YES
Kevin Ollivier wrote:
> Hi Ken,
>
> On Aug 14, 2007, at 11:23 AM, Ken Seehart wrote:
>
>> Kevin Ollivier wrote:
>>> Hi Ken,
>>>
>>> On Aug 13, 2007, at 3:02 PM, Ken Seehart wrote:
>>>
>>>> Kevin Ollivier wrote:
>>>>> . . .
>>>>> It would be great if you could put together a complete sample code that reproduces the problem. I haven't seen anything like this yet myself but it sounds like a pretty serious issue so anything that would help me reproduce it would be greatly appreciated!
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Kevin
>>>> Okay, try this attachment.... It crashes on initialization. I've marked the problem spot.
>>>
>>> Thanks! :-) I just took a look at the sample; have you tried changing load: to load:// and file: to file://, or is there some reason you're not using that format? That is how you're supposed to create custom protocols. It still shouldn't crash, but it's possible it's getting confused by the URLs since they're not in a standard format. ("name:" is reserved for actions, like "javascript:" or "mailto:" It could be that the cache system never expects to see a URL of this format.)
>> Sorry about the confusion, but the load: protocol is not in any way related to the bug.
>>
>> This is just a sample where I have left out some irrelevant code.
>
> I think you are misunderstanding my point. I was not suggesting that the implementation of your load or file protocol handlers might be causing troubles. I was asking whether adding "//" at the end of your protocol name in the HTML code, e.g. using load:// instead of load:, would stop the crash.
>
>> In fact, the crash occurs even if you remove the load: links completely. The second execution of p2.SetPageSource(page2a) causes the crash, as indicated in the comments. The <image> tags are sufficient to cause the crash, provided that the page2a contains at least one image that is not contained in page1a. On the other hand, if the <image> tags are made harmless (e.g. by using the same image in both pages), the load: links work perfectly.
>>
>> Now I realize that calling SetPageSource twice in a row is an odd thing to do. I obviously don't do this explicitly in my real application. However, calling SetPageSource twice in a row is a simple and elegant way to demonstrate the crash. I think you would agree that it should be perfectly safe to call SetPageSource twice in a row, and that if it is not safe to do so, that one would expect other problems as well.
>>
>> I suspect that the cache management code is not entirely robust. It should not be sensitive to the order in which API functions are called.
>
> The question is why it is even trying to cache it at all. How could wxWebKit possibly cache "file:pisces.png"? If it were "file://pisces.png", then yes, I would expect wxWebKit to cache that. But wxWebKit has no way of knowing what "file:pisces.png" refers to, so it should just leave it to your app to handle it. I suspect the real issue in this case is that WebKit assumes that it can parse and handle any URL passed in as a src of an <image> tag itself, which, in this case, is an assumption your code is breaking. It shouldn't crash, regardless, but I don't see how it could work, either.
>
> Thanks,
>
> Kevin
>
>> - Ken
>>
>
#!/usr/bin/env python
import wx, re
from wx import webview
page1 = """
<html><head></head>
<body>
<image src="http://seehart.com/cruise/images/sm_P4290023.jpg" />
</body>
</html>
"""
class Frame(wx.Frame):
"""Frame class that displays an image."""
def __init__(self, parent=None, id=-1,
pos=wx.DefaultPosition, title="Hey wow, it didn't crash yet!"):
wx.Frame.__init__(self, parent, id, title)
p1 = webview.WebView(self, -1)
p1.SetPageSource(page1)
#p1.SetPageSource(page1) # this redundant call causes a crash
# try various combinations with CallAfter and CallLater
# they all crash...
#wx.CallAfter(p1.SetPageSource, page1)
wx.CallAfter(p1.SetPageSource, page1)
class App(wx.App):
"""Application class."""
def OnInit(self):
self.frame = Frame()
self.frame.Show()
self.SetTopWindow(self.frame)
return True
def main():
app = App()
app.MainLoop()
if __name__ == '__main__':
main()
Logged In: YES
user_id=1558272
Originator: YES
Facts:
1. The protocol of the url is irrelevant, as is the form of the path.
2. Performing SetPageSource twice in succession with pages that contain the same image file will cause a crash.
3. The crash is caused by an error in keeping track of the number of requests to a cached image.
4. Creating a second window containing the offending images (and keeping it open the whole time) suppresses the crash by keeping the request count above -1.
In the last message, I gave a simple code example where you simply call SetPageSource twice on the same url. The purpose of the sample is to provide a simple means of reproducing the bug. Obviously calling SetPageSource twice like that would not be a very useful thing to do in a real application, but that is completely beside the point. The general case is devastating in numerous relevant situations.
The C++ assertion is:
ASSERTION FAILED: m_requestCount > -1
(../..\loader\DocLoader.cpp:220 WebCore::DocLoader::decrementRequestCount)
The bug can probably be fixed by finding out why calls to incrementRequestCount and decrementRequestCount become unbalanced.