Thanks Alexey. Sure enough, it’s crashing in WTF::Unicode::convertUTF16ToUTF8. The relevant backtrace:
> * frame #0: 0x00007fff91ac1984 > JavaScriptCore`WTF::Unicode::convertUTF16ToUTF8(unsigned short const**, > unsigned short const*, char**, char*, bool) + 404 > frame #1: 0x00007fff91f1c831 > JavaScriptCore`WTF::StringImpl::utf8Impl(unsigned short const*, unsigned int, > char*&, unsigned long, WTF::ConversionMode) + 193 > frame #2: 0x00007fff91f1caf1 > JavaScriptCore`WTF::StringImpl::utf8ForRange(unsigned int, unsigned int, > WTF::ConversionMode) const + 257 > frame #3: 0x00007fff91f1cb98 > JavaScriptCore`WTF::StringImpl::utf8(WTF::ConversionMode) const + 24 > frame #4: 0x00007fff91f1f3e9 > JavaScriptCore`WTF::String::utf8(WTF::ConversionMode) const + 25 > frame #5: 0x00007fff8f461198 WebKit`+[NSURL(WKExtras) > _web_URLWithWTFString:] + 40 > frame #6: 0x0000000100438f91 WebKit`-[WKWebView URL](self=<unavailable>, > _cmd=<unavailable>) + 65 at WKWebView.mm:502 > frame #7: 0x00007fff8a9a5c3b Foundation`-[NSObject(NSKeyValueCoding) > valueForKey:] + 385 I’m tracing through the code now to see if I can find the problem. I’ll let you know what I find. - Talus. > On 2015 Aug 9, at 16:29, Alexey Proskuryakov <[email protected]> wrote: > > Hi, > > I haven't heard of this before. Could you please try running your application > with GuardMalloc, to check if there are any obvious signs of memory > corruption? If it doesn't catch anything, please file a bug with a test > project that reproduces the problem. > > https://developer.apple.com/library/mac/documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html > > - Alexey > >> 9 авг. 2015 г., в 15:09, Talus Baddley <[email protected]> написал(а): > >> >> Hi. I’m seeing something very strange, and I’m wondering if anyone’s come >> across this issue. >> >> Most of the time, -[WKWebView URL] returns an NSURL, filled with, well, >> percent-encoded garbage data, such as >> >>> %E7%91%A8%E7%81%B4%E3%A9%B3%E2%BC%AF%E6%B9%A5%E7%9C%AE%E6%AD%A9%E6%A5%B4%E6%B9%AF%E7%89%A1%E2%B9%B9%E7%89%AF%E2%BD%A7%E6%A5%B7%E6%A5%AB%E6%90%AF%E6%85%B2%E6%9D%B5%E7%91%A8%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00 >> >> >> As far as I can tell, this isn’t encoding any reasonable, ASCII- or UTF-like >> representation of a string starting “http.” Interestingly, the number of >> bytes encoded in this “URL” is the same as that of the UTF-16 encoded actual >> URL, but there’s that suspicious string of NULs at the end, which makes it >> seem to me like there’s a haywire pointer somewhere. >> >> The first request in the web view reports the correct, well-formed URL. >> >> Has anyone seen this before? >> >> Thanks. >> - Talus. >> _______________________________________________ >> webkit-help mailing list >> [email protected] >> https://lists.webkit.org/mailman/listinfo/webkit-help > > _______________________________________________ webkit-help mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-help
