With WebkitGtk from git, head c8611d3830e3006add30b83419ac0f44d00e2cbc, I have been getting freqeunt, but hard to trigger, crashes. I managed to get a backtrace by running Midori in gdb and waiting, but I had a few tabs loading and wasn't sure which page triggered it.
It seems that with the libsoup backend, it seems that occasionally the m_responseMimeType is the null string. The backtrace is attached, and hopefully I'll have a patch soon.
#0 0xb79b8989 in jsRegExpExecute (re=0x83a1120, subject=0x0, length=0, start_offset=0, offsets=0x8323fbc, offsetcount=30)
#1 0xb76a8621 in WebCore::RegularExpression::match (this=0xb7f55900, str=@0x842eae0, startFrom=0, matchLength=0x0)
#2 0xb733c589 in WebCore::DOMImplementation::isXMLMIMEType (mimeType=@0x842eae0)
#3 0xb733ceea in WebCore::DOMImplementation::createDocument (this=0x8210040, type=@0x842eae0, frame=0x82da288, inViewSourceMode=false)
#4 0xb75a2583 in WebCore::FrameLoader::begin (this=0x842e9e8, url=@0x842eb18, dispatch=false, origin=0x0)
#5 0xb75b150c in WebCore::FrameLoader::receivedFirstData (this=0x842e9e8)
#6 0xb75b2081 in WebCore::FrameLoader::setEncoding (this=0x842e9e8, name=@0xbfce4008, userChosen=false)
#7 0xb6f70cff in WebKit::FrameLoaderClient::finishedLoading (this=0x838ac28, documentLoader=0x8451470)
#8 0xb759669e in WebCore::FrameLoader::finishedLoadingDocument (this=0x842e9e8, loader=0x8451470)
#9 0xb75901a6 in WebCore::DocumentLoader::finishedLoading (this=0x8451470)
#10 0xb75a8a6b in WebCore::FrameLoader::finishedLoading (this=0x842e9e8) at WebCore/loader/FrameLoader.cpp:2804
#11 0xb75d97c9 in WebCore::MainResourceLoader::didFinishLoading (this=0x843dd00)
#12 0xb75e4ab1 in WebCore::ResourceLoader::didFinishLoading (this=0x843dd00)
#13 0xb77dea91 in dataCallback (session=0x81eaf28, msg=0x825c780, data=0x83a0028)
#14 0xb6122916 in ?? () from /usr/lib/libsoup-2.4.so.1
Created attachment 19861 [details]
Set a default mimetype
Here's a patch that I believe will fix the crash, although I would need more testing to be sure, and I'm not entirely certain it is the correct fix, since the sites I was loading when Midori crashed were definitely not text/plain type.
IIRC lack of Content-Type HTTP header should be treated as application/octet-stream rather than text/plain. Should be mentioned in the HTTP RFC.
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
The patch matches what is in the curl backend, but appears wrong given the HTTP 1.1 specification quoted above.
Comment on attachment 19861 [details]
Set a default mimetype
This needs a comment and a changelog. The comment should explain that this is normal behavior for soup to return n empty string to mean text/plain or whatever this change is actually supposed to be fixing.
See also: bug 20257 (using curl).
I believe this problem has gone away after this: http://trac.webkit.org/changeset/41481.
I'm closing on that basis, but if you think there's still something to be done, please reopen.