Bug 136451 - ASSERTION FAILED: url == m_string in WebCore::URL::URL when parsing "file:c"
Summary: ASSERTION FAILED: url == m_string in WebCore::URL::URL when parsing "file:c"
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 116980
  Show dependency treegraph
 
Reported: 2014-09-02 06:56 PDT by Renata Hodovan
Modified: 2021-08-02 10:33 PDT (History)
6 users (show)

See Also:


Attachments
Test case (53 bytes, text/html)
2014-09-02 06:56 PDT, Renata Hodovan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Renata Hodovan 2014-09-02 06:56:47 PDT
Created attachment 237485 [details]
Test case

Load the following test via http to reproduce the issue:

<script>
    window.location.href="file:c";
</script>

Backtrace:

Breakpoint 1, WebCore::URL::URL (this=0x7fffffffcba0, url=...) at /home/reni/data/REPOS/webkit/Source/WebCore/platform/URL.cpp:331
331     ASSERT(url == m_string);
(gdb) bt
#0  WebCore::URL::URL (this=0x7fffffffcba0, url=...) at /home/reni/data/REPOS/webkit/Source/WebCore/platform/URL.cpp:331
#1  0x00007ffff2bc31dd in WebCore::FrameLoader::init (this=0x6d2718) at /home/reni/data/REPOS/webkit/Source/WebCore/loader/FrameLoader.cpp:268
#2  0x00007ffff1f8f8dc in WebCore::Frame::init (this=0x6d2680) at /home/reni/data/REPOS/webkit/Source/WebCore/page/Frame.h:322
#3  0x00007ffff1f8ced2 in WebKit::WebFrame::createWithCoreMainFrame (page=0x6c8530, coreFrame=0x6d2680)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/WebProcess/WebPage/WebFrame.cpp:116
#4  0x00007ffff1f96286 in WebKit::WebPage::WebPage (this=0x6c8530, pageID=1, parameters=...)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/WebProcess/WebPage/WebPage.cpp:375
#5  0x00007ffff1f956d9 in WebKit::WebPage::create (pageID=1, parameters=...)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/WebProcess/WebPage/WebPage.cpp:234
#6  0x00007ffff1e88d5e in WebKit::WebProcess::createWebPage (this=0x6beea0, pageID=1, parameters=...)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/WebProcess/WebProcess.cpp:539
#7  0x00007ffff20cb21b in IPC::callMemberFunctionImpl<WebKit::WebProcess, void (WebKit::WebProcess::*)(unsigned long, WebKit::WebPageCreationParameters const&), std::tuple<unsigned long, WebKit::WebPageCreationParameters>, 0ul, 1ul>(WebKit::WebProcess*, void (WebKit::WebProcess::*)(unsigned long, WebKit::WebPageCreationParameters const&), std::tuple<unsigned long, WebKit::WebPageCreationParameters>&&, std::index_sequence<0ul, 1ul>) (
    object=0x6beea0, function=
    (void (WebKit::WebProcess::*)(WebKit::WebProcess * const, unsigned long, const WebKit::WebPageCreationParameters &)) 0x7ffff1e88cbc <WebKit::WebProcess::createWebPage(unsigned long, WebKit::WebPageCreationParameters const&)>, 
    args=<unknown type in /home/reni/data/REPOS/webkit/WebKitBuild/Debug/lib/libewebkit2.so.1, CU 0x6c5fce8, DIE 0x6d05b78>)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/Platform/IPC/HandleMessage.h:16
#8  0x00007ffff20ca83c in IPC::callMemberFunction<WebKit::WebProcess, void (WebKit::WebProcess::*)(unsigned long, WebKit::WebPageCreationParameters const&), std::tuple<unsigned long, WebKit::WebPageCreationParameters>, std::make_index_sequence<2ul> >(std::tuple<unsigned long, WebKit::WebPageCreationParameters>&&, WebKit::WebProcess*, void (WebKit::WebProcess::*)(unsigned long, WebKit::WebPageCreationParameters const&)) (
    args=<unknown type in /home/reni/data/REPOS/webkit/WebKitBuild/Debug/lib/libewebkit2.so.1, CU 0x6c5fce8, DIE 0x6d05b78>, object=0x6beea0, 
    function=
    (void (WebKit::WebProcess::*)(WebKit::WebProcess * const, unsigned long, const WebKit::WebPageCreationParameters &)) 0x7ffff1e88cbc <WebKit::WebProcess::createWebPage(unsigned long, WebKit::WebPageCreationParameters const&)>)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/Platform/IPC/HandleMessage.h:22
#9  0x00007ffff20c88b1 in IPC::handleMessage<Messages::WebProcess::CreateWebPage, WebKit::WebProcess, void (WebKit::WebProcess::*)(unsigned long, WebKit::WebPageCreationParameters const&)> (decoder=..., object=0x6beea0, function=
    (void (WebKit::WebProcess::*)(WebKit::WebProcess * const, unsigned long, const WebKit::WebPageCreationParameters &)) 0x7ffff1e88cbc <WebKit::WebProcess::createWebPage(unsigned long, WebKit::WebPageCreationParameters const&)>)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/Platform/IPC/HandleMessage.h:120
#10 0x00007ffff20c754e in WebKit::WebProcess::didReceiveWebProcessMessage (this=0x6beea0, decoder=...)
    at /home/reni/data/REPOS/webkit/WebKitBuild/Debug/DerivedSources/WebKit2/WebProcessMessageReceiver.cpp:58
#11 0x00007ffff1e89163 in WebKit::WebProcess::didReceiveMessage (this=0x6beea0, connection=0x6c0a90, decoder=...)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/WebProcess/WebProcess.cpp:600
#12 0x00007ffff1caaeee in IPC::Connection::dispatchMessage (this=0x6c0a90, decoder=...)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/Platform/IPC/Connection.cpp:809
#13 0x00007ffff1caafba in IPC::Connection::dispatchMessage (this=0x6c0a90, message=...)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/Platform/IPC/Connection.cpp:828
#14 0x00007ffff1cab17b in IPC::Connection::dispatchOneMessage (this=0x6c0a90)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/Platform/IPC/Connection.cpp:856
#15 0x00007ffff1cbb1e3 in WTF::FunctionWrapper<void (IPC::Connection::*)()>::operator() (this=0x7fff90001710, c=0x6c0a90)
    at /home/reni/data/REPOS/webkit/Source/WTF/wtf/Functional.h:218
#16 0x00007ffff1cbaf56 in WTF::BoundFunctionImpl<WTF::FunctionWrapper<void (IPC::Connection::*)()>, void (IPC::Connection*)>::operator()() (
    this=0x7fff90001700) at /home/reni/data/REPOS/webkit/Source/WTF/wtf/Functional.h:496
#17 0x00007ffff1cb3e6d in WTF::Function<void ()>::operator()() const (this=0x7fff90001730)
    at /home/reni/data/REPOS/webkit/Source/WTF/wtf/Functional.h:704
#18 0x00007ffff1cb0305 in std::_Function_handler<void (), WTF::Function<void ()> >::_M_invoke(std::_Any_data const&) (__functor=...)
    at /usr/include/c++/4.8/functional:2071
#19 0x00007ffff1cc3ff8 in std::function<void ()>::operator()() const (this=0x7fffffffd740) at /usr/include/c++/4.8/functional:2464
#20 0x00007ffff3f0961b in WTF::RunLoop::performWork (this=0x6bedb0) at /home/reni/data/REPOS/webkit/Source/WTF/wtf/RunLoop.cpp:119
#21 0x00007ffff3f3a7ce in WTF::RunLoop::wakeUpEvent (data=0x6bedb0) at /home/reni/data/REPOS/webkit/Source/WTF/wtf/efl/RunLoopEfl.cpp:68
#22 0x00007fffec68a0bf in _ecore_pipe_handler_call (p=p@entry=0x6578a0, buf=0x663460 "W0l", len=<optimized out>) at lib/ecore/ecore_pipe.c:599
#23 0x00007fffec68a84a in _ecore_pipe_read (data=0x6578a0, fd_handler=<optimized out>) at lib/ecore/ecore_pipe.c:725
#24 0x00007fffec689851 in _ecore_call_fd_cb (fd_handler=0x6550b0, data=<optimized out>, func=<optimized out>) at lib/ecore/ecore_private.h:383
#25 _ecore_main_fd_handlers_call () at lib/ecore/ecore_main.c:1781
#26 _ecore_main_loop_iterate_internal (once_only=once_only@entry=0) at lib/ecore/ecore_main.c:2032
#27 0x00007fffec689a57 in ecore_main_loop_begin () at lib/ecore/ecore_main.c:1042
#28 0x00007ffff3f3a75f in WTF::RunLoop::run () at /home/reni/data/REPOS/webkit/Source/WTF/wtf/efl/RunLoopEfl.cpp:51
#29 0x00007ffff2070fe6 in WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain> (argc=2, argv=0x7fffffffda68)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/Shared/unix/ChildProcessMain.h:61
#30 0x00007ffff2070dc4 in WebKit::WebProcessMainUnix (argc=2, argv=0x7fffffffda68)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/WebProcess/efl/WebProcessMainEfl.cpp:124
#31 0x000000000040084d in main (argc=2, argv=0x7fffffffda68)
    at /home/reni/data/REPOS/webkit/Source/WebKit2/WebProcess/EntryPoint/unix/WebProcessMain.cpp:32
Comment 1 Benjamin Poulain 2014-09-02 15:06:22 PDT
It is crazy how often the URL constructors are misused :(

There is a comment explaining when to use that constructor, and it is ignored all the time.
Comment 2 Darin Adler 2014-09-03 23:29:46 PDT
(In reply to comment #1)
> It is crazy how often the URL constructors are misused :(
> 
> There is a comment explaining when to use that constructor, and it is ignored all the time.

We need to make it easier to use it correctly. Maybe a different type for parsed URL strings other than just String, like AtomicString.
Comment 3 Brent Fulgham 2016-08-03 17:02:40 PDT
This problem does not reproduce under GuardMalloc or ASAN under r204037. If you believe there is still a problem, please reopen this bug and provide an updated test case.