| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
URLRequest. This URLRequest, if valid, is deleted when the IO thread
is being shutdown by way of a DestructionObserver attached to the IO
thread. Prior to this patch this proves problematic as the LeakTracker
is run before DestructionObservers, which means we were errorenously
detecting a leak and causing random UI failures (and perhaps other
tests).
To fix this I've moved the LeakTracker to run after the IO thread
MessageLoop has been deleted (which means DestructionObservers have
been notified). Doing this triggered a DCHECK in
ChromeNetLog::AddEntry:
DCHECK(ChromeThread::CurrentlyOn(ChromeThread::IO));
Here's the full stack:
StackTrace::StackTrace() [0xf247c1]
logging::LogMessage::~LogMessage() [0xf3ef4f]
ChromeNetLog::AddEntry() [0x5c9639]
net::BoundNetLog::AddEntry() [0x147d8a3]
net::BoundNetLog::AddEvent() [0x147d92a]
net::internal::ClientSocketPoolBaseHelper::CancelRequest() [0x132d032]
net::ClientSocketPoolBase<>::CancelRequest() [0x134aabd]
net::TCPClientSocketPool::CancelRequest() [0x1348fdb]
net::ClientSocketHandle::ResetInternal() [0x13273b7]
net::ClientSocketHandle::Reset() [0x1327874]
net::ClientSocketHandle::~ClientSocketHandle() [0x1327895]
scoped_ptr<>::~scoped_ptr() [0x1304b97]
net::HttpStreamRequest::~HttpStreamRequest() [0x1300933]
base::RefCounted<>::Release() [0xa15b83]
scoped_refptr<>::operator=() [0x12f2da4]
net::HttpNetworkTransaction::~HttpNetworkTransaction() [0x12ee377]
scoped_ptr<>::~scoped_ptr() [0x12e2724]
net::HttpCache::Transaction::~Transaction() [0x12e10a6]
scoped_ptr<>::reset() [0x12d1f0b]
URLRequestHttpJob::DestroyTransaction() [0x142229e]
URLRequestHttpJob::Kill() [0x14252e5]
URLRequest::DoCancel() [0x137af1e]
URLRequest::Cancel() [0x137b081]
(anonymous namespace)::OCSPRequestSession::CancelURLRequest() [0x13142a7]
(anonymous namespace)::OCSPRequestSession::WillDestroyCurrentMessageLoop() [0x1314b30]
MessageLoop::~MessageLoop() [0xf421ab]
base::Thread::ThreadMain() [0xf71395]
ThreadFunc() [0xf54338]
start_thread [0x7ff66c6d83f7]
0x7ff669d5cbbd
This is still on the IO thread, but the DCHECK fails because at the
time the DestructionObservers are run Thread::message_loop() returns
NULL, which means the DCHECK fails. I've fixed this by changing the
DCHECK to pass if the current thread's message loop is NULL. I feel a
bit quesy about this as it seems a bit fragile (well, all this code is
fragile). I would be inclined to make Thread::message_loop() return
the MessageLoop until after the destructor has run, but this seems
equally risky. Let me know what you prefer.
BUG=52022
TEST=none
Review URL: http://codereview.chromium.org/3402006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59566 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
Http cache.
BUG=26730
TEST=none
Review URL: http://codereview.chromium.org/1989014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47564 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
used to create an implementation that targets the current thread's message loop.
BUG=None
TEST=Unit tests provided.
Review URL: http://codereview.chromium.org/1837003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46591 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
ChromeThread. This will allow us to make UrlFetcher independent of ChromeThread and we can then move it to chrome/common.
BUG=None
TEST=UrlFetcher unit-tests
Review URL: http://codereview.chromium.org/1702016
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46282 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
interface to the Post* methods
of a message loop. This class can outlive the target message loop. Changed ChromeThread to vend an implementation of this proxy.
BUG=None
TEST=ChromeThread unit-tests modified.
Review URL: http://codereview.chromium.org/1800008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45907 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/1623014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44635 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/656009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41067 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add() and Remove() are called from same thread.
Note I already checked in a fix for the bug. The CL
is trying to check whether the issue exists in other
code path.
TEST=none
BUG=27834
Review URL: http://codereview.chromium.org/449044
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33802 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
BUG=28501
Review URL: http://codereview.chromium.org/435001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32832 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
This allows DCHECKs that the code is running on the correct thread to succeed.
BUG=26714
Review URL: http://codereview.chromium.org/363010
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31010 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
BUG=25354
Review URL: http://codereview.chromium.org/345037
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30790 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
different thread lifetimes.The rest of the code doesn't get MessageLoop pointers since they're not thread-safe and instead just call PostTask on ChromeThread. If the target thread is not alive, then the task is simply deleted.In a followup change, I'll remove any remaining MessageLoop* caching. With this change, there's little to be gained by caching since no locks are involved if the target MessageLoop is guaranteed to outlive the current thread (inferred automatically by the order of the chrome_threads_ array).BUG=25354
Review URL: http://codereview.chromium.org/306032
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30163 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
than one history thread.
We hope to have a hard unit test dependency on buildbot soon, but we need to fix our tests again now.
BUG=22056
Review URL: http://codereview.chromium.org/215023
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26709 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/171088
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23605 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
thread (before/after the IO thread is started/stopped). The WebKit thread is created lazily as needed (while on the IO thread).TEST=noneBUG=none
Review URL: http://codereview.chromium.org/149238
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20109 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(r14075 take two)
Currently we perform several X operations on the IO thread including
geometry and clipboard work. This is causing races inside Xlib and
crashing the browser.
These are the result of synchronous calls from the renderer, so we
cannot route these requests to the UI thread without risking deadlock.
Thus we introduce the UI2 thread. This thread has a second connection
to the X server and can perform X operations safely the without UI
thread.
Work remains to be done:
Since we still have the hack where we pass GtkWidget pointers into the
renderer and back, we still have to access these structures from the
IO and UI2 threads. This still needs to be fixed, but this is not the
patch for it.
Also, not all the X calls from the IO thread have been moved over in
this patch; just a few small ones.
http://codereview.chromium.org/67145
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14206 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
Reverts r14075
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14080 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we perform several X operations on the IO thread including
geometry and clipboard work. This is causing races inside Xlib and
crashing the browser.
These are the result of synchronous calls from the renderer, so we
cannot route these requests to the UI thread without risking deadlock.
Thus we introduce the UI2 thread. This thread has a second connection
to the X server and can perform X operations safely the without UI
thread.
Work remains to be done:
Since we still have the hack where we pass GtkWidget pointers into the
renderer and back, we still have to access these structures from the
IO and UI2 threads. This still needs to be fixed, but this is not the
patch for it.
Also, not all the X calls from the IO thread have been moved over in
this patch; just a few small ones.
http://codereview.chromium.org/67145
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14075 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had originally planned to push history_thread up to BrowserProcess,
but was scared away by the comment in ~Profile that talks about HistoryService
calling back into the bookmark bar model, and that it depended on join()ing at
that particular time to ensure this doesn't happen after the bookmark bar model has been reset.
I didn't use scoped_ptr for the thread because it makes the little dance
in CleanUp awkward.
TEST=any existing test that exersizes the history service. I added a ProfileManager
test that would fail without this change.
Review URL: http://codereview.chromium.org/73012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13703 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
Normalize end of file newlines in chrome/. All files end in a single newline.
Review URL: http://codereview.chromium.org/42015
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11331 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
|