New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 4 users
Status: Fixed
Owner:
Closed: Jan 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocking:
issue 331097



Sign in to add a comment
"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 ?? ()

 
I get stack [1] all the time, but never [2] :-/

If you can still reproduce, can you please in content/child/resource_dispatcher.cc in IPCResourceLoaderBridge's ctor turn the DumpWithoutCrashing() call into a DCHECK(false) and post the backtrace you get?
of course if you could also print the url and the referrer, that would be great
Owner: jochen@chromium.org
Status: Assigned
actually, I managed to reproduce this

It's missing step 0) google for the blog
Cc: japhet@chromium.org
Labels: -OS-Linux OS-All
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.
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).
Blocking: chromium:331097
Project Member Comment 7 by bugdroid1@chromium.org, 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
------------------------------------------------------------------------
Comment 8 by jochen@chromium.org, Jan 10 2014
Issue 332420 has been merged into this issue.
Comment 9 by jochen@chromium.org, Jan 10 2014
Status: Fixed
Project Member Comment 10 by bugdroid1@chromium.org, 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
------------------------------------------------------------------------
Comment 11 by mark@chromium.org, Jan 10 2014
Labels: M-34
 Issue 413204  has been merged into this issue.
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