This is a reland of commit 235af46635
Reason for revert:
LUCI Bisection has identified this change as the cause of a test failure. See the analysis: https://ci.chromium.org/ui/p/chromium/bisection/test-analysis/b/5650878292819968
Fix: initialize TraceEventHandle to 0 to avoid
MemorySanitizer: use-of-uninitialized-value error
Original change's description:
> [tracing] Cleanup up trace_log
>
> This CL cleans up some of the unused functionalities in trace_log
> - legacy metadata
> - member AddTraceEvent* function: replaced by static ones
> - SetTrackDescriptor: covered by TrackNameRecorder
> We no longer update SetTrackDescriptor on UpdateProcessLabel;
> this is unnecessary because TrackNameRecorder calls
> SetTrackDescriptor when the session ends.
>
> Bug: 343404899
> Change-Id: Ia3c4524cd3b3dd4d4ad12a0348e60480b5d03f67
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6120057
> Reviewed-by: Derek Schuff <dschuff@chromium.org>
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Alexander Timin <altimin@chromium.org>
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Mikhail Khokhlov <khokhlov@google.com>
> Cr-Commit-Position: refs/heads/main@{#1403710}
Bug: 343404899
Change-Id: Icb14722297b39f3b8fc7be0985452182a7b5846f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6163823
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Mikhail Khokhlov <khokhlov@google.com>
Reviewed-by: Derek Schuff <dschuff@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404225}
This CL cleans up some of the unused functionalities in trace_log
- legacy metadata
- member AddTraceEvent* function: replaced by static ones
- SetTrackDescriptor: covered by TrackNameRecorder
We no longer update SetTrackDescriptor on UpdateProcessLabel;
this is unnecessary because TrackNameRecorder calls
SetTrackDescriptor when the session ends.
Bug: 343404899
Change-Id: Ia3c4524cd3b3dd4d4ad12a0348e60480b5d03f67
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6120057
Reviewed-by: Derek Schuff <dschuff@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Mikhail Khokhlov <khokhlov@google.com>
Cr-Commit-Position: refs/heads/main@{#1403710}
When investigating shutdown hangs it can be important to know key times
like when shutdown started, when a particular task was started, and when
a shutdown hang was detected. Previously this information was difficult
to obtain but this change puts these three times in local variables in
the appropriate threads, using base::debug::Alias() to lock them there.
This allows determining, for instance, how long the shutdown-hang
timeout was, and whether a task was started before or after shutdown was
initiated.
Bug: 1431378
Change-Id: Ic5a79c5e004e1b6fc11d37b1d6f409b6affac069
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4424837
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Olivier Li <olivierli@chromium.org>
Reviewed-by: Francois Pierre Doray <fdoray@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Steven Holte <holte@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1133121}
Allow the code to use CurrentProcess in base to set process_name(eg.
Browser, Renderer etc.) and process_type to allow splitting
tasks/IPCs per process instead of TraceLog.
Bug: b/242853904
Change-Id: I04e8609baede826f91ab261dd486d53ed22051be
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3997531
Commit-Queue: Aman Verma <amanvr@google.com>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1071557}
This CL is fixing passing to TRACE_ID_WITH_SCOPE a TRACE_ID_LOCAL.
As described on crbug/1269403, we currently emit all the RendererMain
trace event into the browser process, as the same context.
The macro TRACE_ID_WITH_SCOPE is taking an ID which can be of three
kind:
1) Raw (raw integer) : You know what you are doing.
2) LocalId : Use this for ids that are unique within a single process.
3) GlobalId : Use this for ids that are unique across processes.
The proposal is to create these events with a the local scope.
R=eseckler,gab
Bug: 1269403
Change-Id: Ie2d16711163e4fff316da037e2323658643eb142
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3276036
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Commit-Queue: Etienne Bergeron <etienneb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#943535}
This is taking care of a long-standing TODO to move these OnceClosure
holders rather than copy them around with their OnceClosure* members.
This is a precursor to
https://chromium-review.googlesource.com/c/chromium/src/+/3187153/35#message-fcc92e9f85e73f0e5ba6c03610a95cda8736f1f9
which highlighted a problem where some tests see a non-null
MainFunctionParams::ui_task but running the closure results in a UAF.
Logs show that the test hitting the UAF is not the one setting this
field. This CL makes that impossible and fixes the issue in the
follow-up CL.
This CL is intended to be a logical no-op.
This CL touches a lot of files and must happen all at once.
The core change is that ContentMainParams and MainFunctionParams's
moveable fields (ui_task, created_main_parts_closure, and startup_data)
are now held by moveable types rather than raw pointers.
This trickles in the following chain:
main() (in various *_main.cc)
(or SetUp() in !OS_ANDROID browser_test_base.cc)
-> ContentMain()
-> ContentMainRunnerImpl::Initialize()
(forwards arg into MainFunctionParams)
-> RunBrowser()
-> BrowserMain()
-> BrowserMainRunnerImpl::Initialize()
-> BrowserMainLoop (stores MainFunctionParams)
-> BrowserMainLoop::Init
-> ContentBrowserClient::CreateBrowserMainParts()
-> (Embedder)ContentBrowserClient::CreateBrowserMainParts()
-> (Embedder)BrowserMainParts(Platform)
-> (Embedder)BrowserMainParts
-> RunOtherNamedProcessTypeMain()
-> (Embedder)ContentMainDelegate::RunProcess()
(or)
-> FooMain() (kMainFunctions)
(or)
-> RunZygote()
(creates its own MainFunctionParams)
-> (Embedder)ContentMainDelegate::RunProcess()
(on OS_ANDROID, browser_test_base.cc calls directly into
ContentMainDelegate::RunProcess())
Few of these needed the params after passing them down so a move-only
model was simple to adapt (even if invasive). The few exceptions like
BrowserMainRunnerImpl::Initialize consuming |created_main_parts_closure|
are better off in the new model (where they take the OnceClosure before
passing down the params) because that prevents others down the chain
from having access to a OnceClosure they shouldn't invoke anyways.
Noteworthy:
- ContentMainDelegate::RunProcess():
Returned an exit_code >= 0 to indicate the embedder elected to handle
the run request given these params. With move-only semantics it is
necessary to return the params back when the embedder declines
handling this run request. An absl::variant return value is used
to satisfy this requirement.
- content/public/test/test_launcher.h : GetContentMainParams():
Becomes CopyContentMainParams() and only exposes a copy of copyable
params. Uses new ContentMainParams::ShallowCopyForTesting() which
verifies that moveable fields are still null by that time as should be
the case in the order browser tests are initialized.
- MainFunctionParams::command_line being const& violated the style-guide
rule to "avoid defining functions that require a const reference
parameter to outlive the call". This also prevented moving. The type
was hence switched to a const CommandLine*.
- BUILD.gn changes for nacl_helper_win_64 which requires static linking
of its minimal //content deps (was previously missing a dep but was
getting away with it because MainFunctionParams was .h only; required
now with .cc). This was already done for static_switches and this CL
adds static_main_function_params, reusing a similar static_features
target that already existed but was no longer required in
/c/nacl/broker, cleaning that up by replacing rather than copying that
target's definition in this CL.
- ContentMainParams::minimal_browser_mode was weirdly passed as a
parameter to ContentMainRunner::Run(bool start_minimal_browser) but
that method also has access to the ContentMainParams originally passed
via ContentMainRunner::Init(). Passing the param again from Run()
would be a use-after-move in content_main.cc, instead
content_main_runner_impl.cc was updated to use the param it already
has in store.
Bug: 1175074
Change-Id: I3af90505525e426383c59107a3903d645d455682
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244976
Commit-Queue: Gabriel Charette <gab@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Owners-Override: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#940478}
The service manager thread and (TODO) ServiceManager might be created
before the full browser starts, and we want to reuse them when starting
the full browser. Therefore, we add a pointer of BrowserStartupData in
MainFunctionParams.
Particularly, in this CL, ContentMainRunnerImpl creates and owns a
BrowserStartupData object. It passes a pointer of the BrowserStartupData
through the main function parameter to BrowserMainLoop.
The BrowserStartupData interface was introduced in:
https://crrev.com/c/1117471.
Bug: 846846, 853308
Change-Id: Ie11063227a670cd8d72935131e854ee2b5c46e4e
Reviewed-on: https://chromium-review.googlesource.com/1108178
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574054}
This is a reland of I23ef57eb52bfb1eb363682dadf98c571c12afcd1.
It was reverted in Ia548067acbf640010f4c8fbed29a0012a274af05. Reason for revert:
Findit (https://goo.gl/kROfz5) identified this CL at revision 557680 as the culprit
for introducing flakiness in the tests as shown on:
https://findit-for-me.appspot.com/waterfall/flake/flake-culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyQwsSDEZsYWtlQ3VscHJpdCIxY2hyb21pdW0vZmM5NTUwMWZiMjllM2U3NDg3ZmZmOThjMTdlNmFhYmExMDQ2YjMzMAw
The data race has been fixed in:
https://chromium-review.googlesource.com/c/chromium/src/+/1064450.
Original change's description:
> Create BrowserThread::IO thread before browser main loop to start
> ServiceManager.
>
> We need a thread to post/execute tasks when starting the
> ServiceManager. This thread needs to be created before the browser
> main loop is initialized, and will be registered as the
> BrowserThread::IO thread which is currently used by ServiceManager
> connections.
>
> The creation of such a thread is moved to service_manager::main via
> MainDelegate::CreateIOThreadAndGetTaskRunner(). Since it requires no
> thread created before calling fork() on posix, we also move the setup
> of sandbox before creating the IO thread.
>
> Bug: 740677, 729596
> Change-Id: I23ef57eb52bfb1eb363682dadf98c571c12afcd1
> Reviewed-on: https://chromium-review.googlesource.com/969098
> Commit-Queue: Xi Han <hanxi@chromium.org>
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#557680}
Bug: 740677, 729596
Change-Id: I9afb0cdc0f11a1d437c2e9bd09c374503c3d5a4b
Reviewed-on: https://chromium-review.googlesource.com/1059949
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Xi Han <hanxi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560724}
ServiceManager.
We need a thread to post/execute tasks when starting the
ServiceManager. This thread needs to be created before the browser
main loop is initialized, and will be registered as the
BrowserThread::IO thread which is currently used by ServiceManager
connections.
The creation of such a thread is moved to service_manager::main via
MainDelegate::CreateIOThreadAndGetTaskRunner(). Since it requires no
thread created before calling fork() on posix, we also move the setup
of sandbox before creating the IO thread.
Bug: 740677, 729596
Change-Id: I23ef57eb52bfb1eb363682dadf98c571c12afcd1
Reviewed-on: https://chromium-review.googlesource.com/969098
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557680}
Reason for revert:
Prospective revert for nacl_integration crash starting on this build:
https://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%29%281%29/builds/61497
[13142:13142:0309/150217.391584:FATAL:memory_dump_manager.cc(220)] Check failed: !delegate_.
#0 0x7ff7db583b5b base::debug::StackTrace::StackTrace()
#1 0x7ff7db5821ec base::debug::StackTrace::StackTrace()
#2 0x7ff7db5f06df logging::LogMessage::~LogMessage()
#3 0x7ff7db7ac18e base::trace_event::MemoryDumpManager::Initialize()
#4 0x7ff7dd27a73a memory_instrumentation::MemoryDumpManagerDelegateImpl::MemoryDumpManagerDelegateImpl()
#5 0x7ff7dd27a293 memory_instrumentation::MemoryDumpManagerDelegateImpl::Create()
#6 0x7ff7dd26e723 memory_instrumentation::CoordinatorImpl::CoordinatorImpl()
#7 0x7ff7dd26e4da memory_instrumentation::CoordinatorImpl::GetInstance()
#8 0x7ff7dd7dbdc0 ChromeContentBrowserClient::ExposeInterfacesToRenderer()
#9 0x7ff7d54717e8 content::RenderProcessHostImpl::RegisterMojoInterfaces()
#10 0x7ff7d546eb2f content::RenderProcessHostImpl::Init()
#11 0x7ff7d4f41faa content::RenderFrameHostManager::InitRenderView()
#12 0x7ff7d4f3933d content::RenderFrameHostManager::ReinitializeRenderFrame()
#13 0x7ff7d4f37e53 content::RenderFrameHostManager::Navigate()
#14 0x7ff7d4ee1ad3 content::NavigatorImpl::NavigateToEntry()
#15 0x7ff7d4ee2f68 content::NavigatorImpl::NavigateToPendingEntry()
#16 0x7ff7d4eb487a content::NavigationControllerImpl::NavigateToPendingEntryInternal()
#17 0x7ff7d4eacf17 content::NavigationControllerImpl::NavigateToPendingEntry()
#18 0x7ff7d4ead365 content::NavigationControllerImpl::LoadEntry()
#19 0x7ff7d4eaef5c content::NavigationControllerImpl::LoadURLWithParams()
#20 0x7ff7e00a88f4 (anonymous namespace)::LoadURLInContents()
#21 0x7ff7e00a75aa chrome::Navigate()
#22 0x7ff7e00dcac7 StartupBrowserCreatorImpl::OpenTabsInBrowser()
#23 0x7ff7e00dd687 StartupBrowserCreatorImpl::RestoreOrCreateBrowser()
#24 0x7ff7e00dc04d StartupBrowserCreatorImpl::ProcessLaunchUrlsUsingConsolidatedFlow()
#25 0x7ff7e00db4c5 StartupBrowserCreatorImpl::Launch()
#26 0x7ff7e00d5662 StartupBrowserCreator::LaunchBrowser()
#27 0x7ff7e00d4b57 StartupBrowserCreator::ProcessCmdLineImpl()
#28 0x7ff7e00d3ef2 StartupBrowserCreator::Start()
#29 0x7ff7de08f54c ChromeBrowserMainParts::PreMainMessageLoopRunImpl()
#30 0x7ff7de08e130 ChromeBrowserMainParts::PreMainMessageLoopRun()
#31 0x7ff7d4b8e831 content::BrowserMainLoop::PreMainMessageLoopRun()
#32 0x7ff7d3feafe5 _ZN4base8internal13FunctorTraitsIMN7content22IndexedDBCallbacksImpl13InternalStateEFvvEvE6InvokeIPS4_JEEEvS6_OT_DpOT0_
#33 0x7ff7d4b99991 _ZN4base8internal12InvokeHelperILb0EiE8MakeItSoIRKMN7content15BrowserMainLoopEFivEJPS5_EEEiOT_DpOT0_
#34 0x7ff7d4b99937 _ZN4base8internal7InvokerINS0_9BindStateIMN7content15BrowserMainLoopEFivEJNS0_17UnretainedWrapperIS4_EEEEEFivEE7RunImplIRKS6_RKSt5tupleIJS8_EEJLm0EEEEiOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
#35 0x7ff7d4b9987c _ZN4base8internal7InvokerINS0_9BindStateIMN7content15BrowserMainLoopEFivEJNS0_17UnretainedWrapperIS4_EEEEEFivEE3RunEPNS0_13BindStateBaseE
#36 0x7ff7d3ecb53b base::internal::RunMixin<>::Run()
#37 0x7ff7d575e9bb content::StartupTaskRunner::RunAllTasksNow()
#38 0x7ff7d4b8c400 content::BrowserMainLoop::CreateStartupTasks()
#39 0x7ff7d4b9d3c7 content::BrowserMainRunnerImpl::Initialize()
#40 0x7ff7d4b886af content::BrowserMain()
#41 0x7ff7d63fcbd6 content::RunNamedProcessTypeMain()
#42 0x7ff7d63fef7c content::ContentMainRunnerImpl::Run()
#43 0x7ff7d63fbb02 content::ContentMain()
#44 0x7ff7dc6d57da ChromeMain
#45 0x7ff7dc6d5702 main
#46 0x7ff7c7a80f45 __libc_start_main
#47 0x7ff7dc6d5605 <unknown>
Original issue's description:
> memory-infra: Finish moving to Mojo (2nd attempt)
>
> This was originally landed in https://codereview.chromium.org/2694083005.
> But, it broke webview perf tests, and so, it was reverted. It turned out that
> in some scenarios, the memory dump manager is not initialized early enough (in
> the browser process). So, now, I initialize it as soon as the UI thread is
> created.
>
> Modifications since the original CL are:
>
> - The Coordinator service is created when the UI thread is created
> (browser_main_loop.cc).
> - When Coordinator is created, it initializes memory dump manager's TPID
> (memory_dump_manager_delegate_impl.cc).
> - To avoid dependency from //services/resource_coordinator to //content the
> definition of the service TPID is moved from child_process_host.h to
> constants.mojom.
>
> I tested the CL by building for Android and running the following with an
> android device attached:
>
> run_benchmark memory.top_10_mobile --browser=android-webview
> --also-run-disabled-tests
>
> In the original reverted CL, the above command results in
> 'Unable to obtain memory dump' exceptions. With this CL the test runs
> successfully.
>
> An example interaction diagram (to see the large image, click on it):
> https://docs.google.com/document/d/1Mz64egjuZ4WsYw9AKKWdTvl0Il706EWdCy24V87R_F4/edit#heading=h.1ku5wcoxqifr
>
> BUG=679830, 697773, 697384, 697062
>
> Review-Url: https://codereview.chromium.org/2734193002
> Cr-Commit-Position: refs/heads/master@{#455866}
> Committed: 0a3a302b6dTBR=primiano@chromium.org,ssid@chromium.org,kenrb@chromium.org,jam@chromium.org,chiniforooshan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=679830, 697773, 697384, 697062
Review-Url: https://codereview.chromium.org/2738093003
Cr-Commit-Position: refs/heads/master@{#455899}
This was originally landed in https://codereview.chromium.org/2694083005.
But, it broke webview perf tests, and so, it was reverted. It turned out that
in some scenarios, the memory dump manager is not initialized early enough (in
the browser process). So, now, I initialize it as soon as the UI thread is
created.
Modifications since the original CL are:
- The Coordinator service is created when the UI thread is created
(browser_main_loop.cc).
- When Coordinator is created, it initializes memory dump manager's TPID
(memory_dump_manager_delegate_impl.cc).
- To avoid dependency from //services/resource_coordinator to //content the
definition of the service TPID is moved from child_process_host.h to
constants.mojom.
I tested the CL by building for Android and running the following with an
android device attached:
run_benchmark memory.top_10_mobile --browser=android-webview
--also-run-disabled-tests
In the original reverted CL, the above command results in
'Unable to obtain memory dump' exceptions. With this CL the test runs
successfully.
An example interaction diagram (to see the large image, click on it):
https://docs.google.com/document/d/1Mz64egjuZ4WsYw9AKKWdTvl0Il706EWdCy24V87R_F4/edit#heading=h.1ku5wcoxqifr
BUG=679830, 697773, 697384, 697062
Review-Url: https://codereview.chromium.org/2734193002
Cr-Commit-Position: refs/heads/master@{#455866}
Reason for revert:
Unfortunately this broke lot of memory-infra metrics and caused flakiness in various bot.
Have to revert because this is causing problems to the sheriff rotation. More details:
crbug.com/697384 : metrics broken
crbug.com/697062 : memory dumps failing on webview
Original issue's description:
> memory-infra: Finish moving memory_infra from TracingController
>
> This finishes moving memory instrumentation code from TracingController
> to its own location in //services/resource_coordinator.
>
> BUG=679830
> CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
>
> Review-Url: https://codereview.chromium.org/2694083005
> Cr-Commit-Position: refs/heads/master@{#453243}
> Committed: e7bee2f02dTBR=hjd@chromium.org,oysteine@chromium.org,ssid@chromium.org,jam@chromium.org,kenrb@chromium.org,chiniforooshan@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=679830,697384
Review-Url: https://codereview.chromium.org/2724793002
Cr-Commit-Position: refs/heads/master@{#453919}
This finishes moving memory instrumentation code from TracingController
to its own location in //services/resource_coordinator.
BUG=679830
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Review-Url: https://codereview.chromium.org/2694083005
Cr-Commit-Position: refs/heads/master@{#453243}
This blocks the conversion of //base from scoped_ptr to std::unique_ptr.
BUG=554298
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
R=danakj@chromium.org
Review URL: https://codereview.chromium.org/1852953002 .
Cr-Commit-Position: refs/heads/master@{#384767}
All tracing macros can now export events to ETW (see
TraceEventETWExport). Therefore, there is no reason to keep using the
old TRACE_EVENT_*_ETW macros.
The tracing infrastructure doesn't expect synchronous events around
the main loop of a thread. For this reason, the TRACE_EVENT_*_ETW
macros have been replaced by TRACE_EVENT_ASYNC_* macros instead of
simple TRACE_EVENT* macros in some cases.
Once this patch has landed, the TRACE_EVENT_*ETW macros will be
removed (https://codereview.chromium.org/1376793004/)
BUG=#1263
BUG=489720
Review URL: https://codereview.chromium.org/1386193002
Cr-Commit-Position: refs/heads/master@{#353076}
This is the last stage of the trace_event directory restructuring.
This is part of a set of 3 CLs which is moving tracing clients to use
the new base::trace_event namespace.
See crrev.com/837303004 and the related bug for motivations.
BUG=451032
TBR=jam@chromium.org
NOTRY=true
Review URL: https://codereview.chromium.org/892213004
Cr-Commit-Position: refs/heads/master@{#315310}
This is just a mechanical rename of tracing includes.
See crrev.com/837303004 and the related bug for motivations.
BUG=451032
TBR=avi@chromium.org
Review URL: https://codereview.chromium.org/866803003
Cr-Commit-Position: refs/heads/master@{#313421}
For the browser use case it is convenient to have a single ContentMain entry point function that handles all initialization, run and shutdown. For embedded use cases it is often necessary to integrate with existing application message loops where initialization and shutdown must be handled separately.
To support sharing of this code the following changes were required:
1. Refactor the ContentMain function to create a ContentMainRunner class containing separate initialization, run and shutdown functions.
2. Refactor the BrowserMain function and BrowserMainLoop class to create a BrowserMainRunner class containing separate initialization, run and shutdown functions.
3. Add a new BrowserMainParts::GetMainMessageLoop method. This is necessary to support creation of a custom MessageLoop implementation while sharing BrowserMainRunner initialization and shutdown code.
BUG=112507
TEST=none
Review URL: https://chromiumcodereview.appspot.com/9375017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@121454 0039d316-1c4b-4281-b951-d872f2087c98
For the browser use case it is convenient to have a single ContentMain entry point function that handles all initialization, run and shutdown. For embedded use cases it is often necessary to integrate with existing application message loops where initialization and shutdown must be handled separately.
To support sharing of this code the following changes were required:
1. Refactor the ContentMain function to create a ContentMainRunner class containing separate initialization, run and shutdown functions.
2. Refactor the BrowserMain function and BrowserMainLoop class to create a BrowserMainRunner class containing separate initialization, run and shutdown functions.
3. Add a new BrowserMainParts::GetMainMessageLoop method. This is necessary to support creation of a custom MessageLoop implementation while sharing BrowserMainRunner initialization and shutdown code.
BUG=112507
TEST=none
Review URL: https://chromiumcodereview.appspot.com/9347022
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@121236 0039d316-1c4b-4281-b951-d872f2087c98
For the browser use case it is convenient to have a single ContentMain entry point function that handles all initialization, run and shutdown. For embedded use cases it is often necessary to integrate with existing application message loops where initialization and shutdown must be handled separately.
To support sharing of this code the following changes were required:
1. Refactor the ContentMain function to create a ContentMainRunner class containing separate initialization, run and shutdown functions.
2. Refactor the BrowserMain function and BrowserMainLoop class to create a BrowserMainRunner class containing separate initialization, run and shutdown functions.
3. Add a new BrowserMainParts::GetMainMessageLoop method. This is necessary to support creation of a custom MessageLoop implementation while sharing BrowserMainRunner initialization and shutdown code.
BUG=112507
TEST=none
Review URL: https://chromiumcodereview.appspot.com/9190018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@120574 0039d316-1c4b-4281-b951-d872f2087c98
-got rid of SandboxInitWrapper, since I didn't see a need to expose given that we can just expose sandbox::SandboxInterfaceInfo
-got rid of the duplicated code to initialize the broker
-since I made MainFunctionParams only have the sandbox struct on Windows, I also made the mac specific auto release pool behind an ifdef as well. It seemed odd to make something so mac specific compile on all platforms to save some #ifdefs.
BUG=98716
Review URL: http://codereview.chromium.org/8414020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107863 0039d316-1c4b-4281-b951-d872f2087c98
Only content/ now has the ability to create BrowserThread objects,
with the exception that tests can create the
content::TestBrowserThread subclass, and (temporarily) code in chrome/
can create the DeprecatedBrowserThread subclass.
A follow-up change will make content/ take care of its own thread
creation, remove DeprecatedBrowserThread, and move all state and
non-trivial constructors from BrowserThread down to BrowserThreadImpl.
Also moved BrowserProcessSubThread into content/ namespace. As part
of follow-up cleanup, chrome/ will stop using this class.
BUG=98716
TEST=existing
Review URL: http://codereview.chromium.org/8392042
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107718 0039d316-1c4b-4281-b951-d872f2087c98
This CL moves GTK and Aura "Parts" out of the primary BrowserMainParts tree and into orthogonal parts that can be added independently. This was done in a way that will facilitate adding additional parts if (when) we need them.
The motivation for this was to
a) eliminate the existing typedef in chrome_browser_main_chromeos.h
b) reduce the number of #ifdefs required in the setup / parts code
For an outline of the new parts see:
https://docs.google.com/drawings/d/1-gIMl-81c4SvcMrT1xaxnDGibDe7VQfMkFT1bMnIvrg/edit?hl=en_US
Please consider this a proposal; I am entirely open to feedback.
BUG=none
TEST=Chrome compiles and passes tests on all platfroms.
Review URL: http://codereview.chromium.org/8302016
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107383 0039d316-1c4b-4281-b951-d872f2087c98
window_container_type.h as well since it is included by
content_browser_client.h
BUG=98716
TEST=it builds + existing tests
Review URL: http://codereview.chromium.org/8346017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@106323 0039d316-1c4b-4281-b951-d872f2087c98
I also did a bunch of cleanup, and transitioned to tracking
the duration of a run, rather than the time from posting
(construction of a task) to completion of the run. It is
less interesting for now to track queueing delay, and we
need a focus on task execution time. I left in the hook
(API) with the expectation that I'll be extending the
tracked_objects code to include this as well.
I also landed changes to run in Linux/Mac. The fact that
I've punted on shutdown made this landing easy (all
code support was previously lost during migration to
some flavor of bind support).
r=willchan,jam,viettrungluu,ajwong
BUG=62728
Review URL: http://codereview.chromium.org/8233037
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@105694 0039d316-1c4b-4281-b951-d872f2087c98
Puts CHECKs in RenderProcessHost's constructor to make sure the main MessageLoop hasn't stopped running yet.
BUG=91398
TEST=none
Review URL: http://codereview.chromium.org/8210004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@104849 0039d316-1c4b-4281-b951-d872f2087c98
aura chrome fails on ubuntu 11.04 without this
remove base::MessagePumpX::DisableGtkMessagePump() from aura as we nolonger has gtk on aura.
BUG=97131
TEST=none
Review URL: http://codereview.chromium.org/8195003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@104508 0039d316-1c4b-4281-b951-d872f2087c98
We promote GTK errors into DFATALs. Some versions of GTK accidentally
call it an error to not have an environment variable set. They fixed
this on GTK trunk, but we shouldn't die on Ubuntu releases that don't
have the fix.
BUG=97293
Review URL: http://codereview.chromium.org/7983018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@102021 0039d316-1c4b-4281-b951-d872f2087c98
This is a temp fix to remove gtk_init. We should remove this once we remove gtk from message pump, which should be done as a part of AURA->TOOLKIT_USES_GTK=0
WindowSizer/gfx::screen for aura
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7943006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@101922 0039d316-1c4b-4281-b951-d872f2087c98
