| "Trying to send secure referrer for insecure load" while loading vimeo.tumblr.com | ||||||
| Project Member Reported by jyasskin@chromium.org, Jan 6 2014 | Back to list | |||||
Synced to r242916, I loaded vimeo.tumblr.com, and the renderer crashed with stack trace [1]. Then I reloaded the tab, and the browser crashed with trace [2]. Now when I re-open the browser and click "Reload" on the "Chrome exited abruptly" infobar, I get trace [2] consistently. Trace [1]: ASSERTION FAILED: delta >= 0 || m_liveSize >= static_cast<size_t>(-delta) ../../third_party/WebKit/Source/core/fetch/MemoryCache.cpp(494) : void WebCore::MemoryCache::adjustSize(bool, ptrdiff_t) 1 0x7f5f8e6957e0 2 0x7f5f8e69f4d5 3 0x7f5f8e6910c8 4 0x7f5f8e691105 5 0x7f5f9621e508 WebCore::BitmapImage::destroyMetadataAndNotify(unsigned long) 6 0x7f5f9621e458 WebCore::BitmapImage::destroyDecodedData(bool) 7 0x7f5f9621e5b5 WebCore::BitmapImage::destroyDecodedDataIfNecessary() 8 0x7f5f96220167 WebCore::BitmapImage::internalAdvanceAnimation(bool) 9 0x7f5f96220020 WebCore::BitmapImage::advanceAnimation(WebCore::Timer<WebCore::BitmapImage>*) 10 0x7f5f96220ae6 11 0x7f5f960e8393 WebCore::ThreadTimers::sharedTimerFiredInternal() 12 0x7f5f960e8105 WebCore::ThreadTimers::sharedTimerFired() 13 0x7f5f93c7e3ed 14 0x7f5f93c7f082 15 0x7f5f93c7efec 16 0x7f5f93c7ef9a 17 0x7f5f97fa032e 18 0x7f5f98155ce2 base::Timer::RunScheduledTask() 19 0x7f5f98155e2c 20 0x7f5f981562f2 21 0x7f5f9815625c 22 0x7f5f98156205 23 0x7f5f97fa032e 24 0x7f5f9806495d base::MessageLoop::RunTask(base::PendingTask const&) 25 0x7f5f98064c7b base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) 26 0x7f5f9806516d base::MessageLoop::DoDelayedWork(base::TimeTicks*) 27 0x7f5f980772a7 28 0x7f5f98064310 base::MessageLoop::RunInternal() 29 0x7f5f98064235 base::MessageLoop::RunHandler() 30 0x7f5f980de812 base::RunLoop::Run() 31 0x7f5f98063b91 base::MessageLoop::Run() Trace [2]: [14399:14430:0106/153327:FATAL:url_request.cc(694)] Trying to send secure referrer for insecure load #0 base::debug::(anonymous namespace)::DebugBreak () at ../../base/debug/debugger_posix.cc:244 #1 0x00007ffff54b9729 in base::debug::BreakDebugger () at ../../base/debug/debugger_posix.cc:257 #2 0x00007ffff5544c72 in logging::LogMessage::~LogMessage (this=0x7fffcfd7f398) at ../../base/logging.cc:651 #3 0x00007ffff4ea6e36 in net::URLRequest::StartJob (this=0x3e3edfd46520, job=0x3e3edfbfb520) at ../../net/url_request/url_request.cc:694 #4 0x00007ffff4ea324b in net::URLRequest::BeforeRequestComplete (this=0x3e3edfd46520, error=0) at ../../net/url_request/url_request.cc:661 #5 0x00007ffff4ea677e in net::URLRequest::Start (this=0x3e3edfd46520) at ../../net/url_request/url_request.cc:626 #6 0x00007fffedd97136 in content::ResourceLoader::StartRequestInternal (this=0x3e3edfa58560) at ../../content/browser/loader/resource_loader.cc:424 #7 0x00007fffedd9702a in content::ResourceLoader::StartRequest (this=0x3e3edfa58560) at ../../content/browser/loader/resource_loader.cc:111 #8 0x00007fffedd611de in content::ResourceDispatcherHostImpl::StartLoading (this=0x3e3edd7018e0, info=0x3e3edeac1430, loader=linked_ptr((content::ResourceLoader *)0x3e3edfa58560)) at ../../content/browser/loader/resource_dispatcher_host_impl.cc:1681 #9 0x00007fffedd59cb8 in content::ResourceDispatcherHostImpl::BeginRequestInternal ( this=0x3e3edd7018e0, request=..., handler=...) at ../../content/browser/loader/resource_dispatcher_host_impl.cc:1673 #10 0x00007fffedd5dddb in content::ResourceDispatcherHostImpl::BeginRequest (this=0x3e3edd7018e0, request_id=0, request_data=..., sync_result=0x0, route_id=2) at ../../content/browser/loader/resource_dispatcher_host_impl.cc:1133 #11 0x00007fffedd5cd46 in content::ResourceDispatcherHostImpl::OnRequestResource ( Python Exception <class 'gdb.error'> Attempt to take contents of a non-pointer value.: this=0x3e3edd7018e0, message=, request_id=0, request_data=...) at ../../content/browser/loader/resource_dispatcher_host_impl.cc:867 #12 0x00007fffedd68f49 in ResourceHostMsg_RequestResource::Dispatch<content::ResourceDispatcherHostImpl, content::ResourceDispatcherHostImpl, int, ResourceHostMsg_Request const&> ( msg=0x7fffcfd82140, obj=0x3e3edd7018e0, sender=0x3e3edd7018e0, func= (void (content::ResourceDispatcherHostImpl::*)(content::ResourceDispatcherHostImpl * const, const IPC::Message &, int, const ResourceHostMsg_Request &)) 0x7fffedd5ccf0 <content::ResourceDispatcherHostImpl::OnRequestResource(IPC::Message const&, int, ResourceHostMsg_Request const&)>) at ../../content/common/resource_messages.h:284 #13 0x00007fffedd5c730 in content::ResourceDispatcherHostImpl::OnMessageReceived ( Python Exception <class 'gdb.error'> Attempt to take contents of a non-pointer value.: this=0x3e3edd7018e0, message=, filter=0x3e3edee34660, message_was_ok=0x7fffcfd81ebf) at ../../content/browser/loader/resource_dispatcher_host_impl.cc:833 #14 0x00007fffedd9f575 in content::ResourceMessageFilter::OnMessageReceived (this=0x3e3edee34660, Python Exception <class 'gdb.error'> Attempt to take contents of a non-pointer value.: message=, message_was_ok=0x7fffcfd81ebf) at ../../content/browser/loader/resource_message_filter.cc:42 #15 0x00007fffed8ea491 in content::BrowserMessageFilter::Internal::DispatchMessage ( Python Exception <class 'gdb.error'> Attempt to take contents of a non-pointer value.: this=0x3e3edf53fbb0, message=) at ../../content/public/browser/browser_message_filter.cc:82 #16 0x00007fffed8e9f4e in content::BrowserMessageFilter::Internal::OnMessageReceived ( Python Exception <class 'gdb.error'> Attempt to take contents of a non-pointer value.: this=0x3e3edf53fbb0, message=) at ../../content/public/browser/browser_message_filter.cc:64 Python Exception <class 'gdb.error'> Attempt to take contents of a non-pointer value.: #17 0x00007ffff3118df5 in IPC::ChannelProxy::Context::TryFilters (this=0x3e3ededc6800, message=) at ../../ipc/ipc_channel_proxy.cc:75 #18 0x00007ffff3118e9f in IPC::ChannelProxy::Context::OnMessageReceived (this=0x3e3ededc6800, Python Exception <class 'gdb.error'> Attempt to take contents of a non-pointer value.: message=) at ../../ipc/ipc_channel_proxy.cc:89 #19 0x00007ffff3122907 in IPC::internal::ChannelReader::DispatchInputData (this=0x3e3edf0ca020, input_data=0x3e3edf0ca030 "\204\001", input_data_len=408) at ../../ipc/ipc_channel_reader.cc:96 #20 0x00007ffff3122512 in IPC::internal::ChannelReader::ProcessIncomingMessages ( this=0x3e3edf0ca020) at ../../ipc/ipc_channel_reader.cc:32 #21 0x00007ffff310bfea in IPC::Channel::ChannelImpl::OnFileCanReadWithoutBlocking ( this=0x3e3edf0ca020, fd=148) at ../../ipc/ipc_channel_posix.cc:670 #22 0x00007ffff310c1b2 in non-virtual thunk to IPC::Channel::ChannelImpl::OnFileCanReadWithoutBlocking(int) () at ../../ipc/ipc_channel_posix.cc:689 #23 0x00007ffff546ac7d in base::MessagePumpLibevent::FileDescriptorWatcher::OnFileCanReadWithoutBlocking (this=0x3e3edf0cb070, fd=148, pump=0x3e3edd866a40) at ../../base/message_loop/message_pump_libevent.cc:99 #24 0x00007ffff546bebe in base::MessagePumpLibevent::OnLibeventNotification (fd=148, flags=2, context=0x3e3edf0cb070) at ../../base/message_loop/message_pump_libevent.cc:356 #25 0x00007ffff569be40 in event_process_active (base=0x3e3edd92e520) at ../../third_party/libevent/event.c:385 #26 0x00007ffff569b422 in event_base_loop (base=0x3e3edd92e520, flags=1) at ../../third_party/libevent/event.c:525 #27 0x00007ffff546c2f1 in base::MessagePumpLibevent::Run (this=0x3e3edd866a40, delegate=0x3e3edd937920) at ../../base/message_loop/message_pump_libevent.cc:269 #28 0x00007ffff5569310 in base::MessageLoop::RunInternal (this=0x3e3edd937920) at ../../base/message_loop/message_loop.cc:449 #29 0x00007ffff5569235 in base::MessageLoop::RunHandler (this=0x3e3edd937920) at ../../base/message_loop/message_loop.cc:421 #30 0x00007ffff55e3812 in base::RunLoop::Run (this=0x7fffcfd83600) at ../../base/run_loop.cc:47 #31 0x00007ffff5568b91 in base::MessageLoop::Run (this=0x3e3edd937920) at ../../base/message_loop/message_loop.cc:314 #32 0x00007ffff56483f9 in base::Thread::Run (this=0x3e3edd8e19b0, message_loop=0x3e3edd937920) at ../../base/threading/thread.cc:172 #33 0x00007fffed9877a8 in content::BrowserThreadImpl::IOThreadRun (this=0x3e3edd8e19b0, message_loop=0x3e3edd937920) at ../../content/browser/browser_thread_impl.cc:162 #34 0x00007fffed987936 in content::BrowserThreadImpl::Run (this=0x3e3edd8e19b0, message_loop=0x3e3edd937920) at ../../content/browser/browser_thread_impl.cc:188 #35 0x00007ffff5648611 in base::Thread::ThreadMain (this=0x3e3edd8e19b0) at ../../base/threading/thread.cc:225 #36 0x00007ffff56316cf in base::(anonymous namespace)::ThreadFunc (params=0x7fffffffc028) at ../../base/threading/platform_thread_posix.cc:80 #37 0x00007fffe3f52e9a in start_thread (arg=0x7fffcfd84700) at pthread_create.c:308 #38 0x00007fffe1c753fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #39 0x0000000000000000 in ?? ()
Comment 1
by
jochen@chromium.org,
Jan 7 2014
,
Jan 7 2014
of course if you could also print the url and the referrer, that would be great
,
Jan 7 2014
actually, I managed to reproduce this It's missing step 0) google for the blog
,
Jan 7 2014
This bug is that in https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/render_view_impl.cc&l=1965 we should take the ds->request() instead of the original_request: when you click on a link in the SRP you get to a page that sets a referrer policy and then redirects to the target. Since we read the policy of the original request, we store the wrong policy. However, when I tried to add a test, I ran into endless fun :( Adding japhet@ who might have some insight to share. When we redirect from https to http, RenderFrameImpl::willSendRequest() appears to be invoked with a different WebURLRequest than RenderFrameImpl::didCommitProvisionalLoad (in that case, the WebURLRequest is frame->dataSource()->request()) and so the referrer policy which is stored as extra data on the request in willSendRequest is lost. Or maybe I'm doing something wrong.
,
Jan 7 2014
Oooh, yes, I bet we copy the request to DocumentLoader::m_request *before* we call willSendRequest. See ResourceLoader::willSendRequest, where we call Resource::redirectReceived (which eventually notifies DocumentLoader) before we call ResourceLoaderHost::willSendrequest (which eventually notifies the embedder).
,
Jan 8 2014
,
Jan 8 2014
The following revision refers to this bug:
http://src.chromium.org/viewvc/blink?view=rev&rev=164696
------------------------------------------------------------------------
r164696 | jochen@chromium.org | 2014-01-08T19:05:01.298794Z
Changed paths:
M http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/RawResource.h?r1=164696&r2=164695&pathrev=164696
M http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/DocumentLoader.h?r1=164696&r2=164695&pathrev=164696
M http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/Resource.h?r1=164696&r2=164695&pathrev=164696
M http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/ResourceLoader.cpp?r1=164696&r2=164695&pathrev=164696
M http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/RawResource.cpp?r1=164696&r2=164695&pathrev=164696
M http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/DocumentLoader.cpp?r1=164696&r2=164695&pathrev=164696
Update the ResourceRequest in DocumentLoader after the embedder modified it
The call on resource will end up calling DocumentLoader::willSendRequest
which stores the request. If we do this before the call on the host
(which will end up calling RenderFrameImpl::willSendRequest),
modifications by the host are not reflected in DocumentLoader::m_request.
BUG= 331941
R=japhet@chromium.org
Review URL: https://codereview.chromium.org/126753002
------------------------------------------------------------------------
,
Jan 10 2014
Issue 332420 has been merged into this issue.
,
Jan 10 2014
,
Jan 10 2014
------------------------------------------------------------------------ r244138 | jochen@chromium.org | 2014-01-10T11:02:20.587999Z Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/frame_host/navigation_controller_impl.cc?r1=244138&r2=244137&pathrev=244138 M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/render_frame_impl.cc?r1=244138&r2=244137&pathrev=244138 M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/render_view_impl.cc?r1=244138&r2=244137&pathrev=244138 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/referrer_policy_browsertest.cc?r1=244138&r2=244137&pathrev=244138 Fix referrer policy passing during redirects We a redirect commits, we should take the referrer policy from the request we actually send and not from the one we intended to send. Also, when the renderer tells the browser about a new navigation, always update the referrer together with the URL Depends on https://codereview.chromium.org/126753002/ in blink BUG= 331941 R=nasko@chromium.org TEST=browser_tests:ReferrerPolicyTest.* Review URL: https://codereview.chromium.org/128173002 ------------------------------------------------------------------------
,
Jan 10 2014
,
Sep 11 2014
Issue 413204 has been merged into this issue.
,
Sep 29 2014
Sorry to intrude, but is the fix for this issue released in v37? I don't see how my issue 413204 could have been merged into a fixed issue if I'm still seeing the problem. |
||||||
| ► Sign in to add a comment | ||||||