Time to kill --single-process?

[Aaron Boodman]

The evidence seems to say that it isn't important, since it doesn't
start up reliably anymore (at least on Linux).

- a

[Scott Graham]

I use it all the time on Windows. Please don't go out of your way to kill it.

- a

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-dev

[Peter Kasting]

On Thu, Apr 5, 2012 at 12:23 PM, Aaron Boodman <a...@chromium.org> wrote:

The evidence seems to say that it isn't important, since it doesn't
start up reliably anymore (at least on Linux).

I still use this on Windows for various kinds of debugging.  I would prefer not to kill it.

PK 

[Rachel Blum]

Use it all the time to debug on OSX. So +1 on the "please don't kill unless you have to".

Rachel

[John Abd-El-Malek]

This is used on Android now for WebView.

I think it's time we add automated tests for it though.

On Thu, Apr 5, 2012 at 12:23 PM, Aaron Boodman <a...@chromium.org> wrote:

[Michael Nordman]

You might want to ping joth and andreip about this too.

[Justin Schuh]

This mode is absolutely essential to the security team's fuzzing work. Multi-process is too slow and eats up too much overhead on cluster-fuzz, and DRT doesn't exercise an identical stack. Killing this mode would basically cripple us.

-j

On Thu, Apr 5, 2012 at 12:25 PM, Rachel Blum <gr...@chromium.org> wrote:

[Peter Kasting]

On Thu, Apr 5, 2012 at 12:34 PM, John Abd-El-Malek <j...@chromium.org> wrote:

This is used on Android now for WebView.

I think it's time we add automated tests for it though.

Wait, are you saying it's used in some user-exposed fashion?

--single-process is known to be seriously broken in major ways, which would be prohibitive to fix.  We should never ever be running this outside of debugging.

PK 

[Abhishek Arya]

All of our fuzzing bots in the security team are based on ASAN linux
builds and we have been reliably using the --single-process mode for a
long time. Please don't kill it.

Cheers,
Abhishek

[Gavin Peters (蓋文彼德斯)]

I have been using it daily for debugging for ages.  When did it break for you?  I last pulled to trunk a few days ago and I've done a lot of debugging in it since then.

Please leave it in.  If I see the same problems, I may well go ahead and fix it.  I bet others would do the same.

- Gavin

- a

[Tom Hudson]

On Thu, Apr 5, 2012 at 3:42 PM, Gavin Peters (蓋文彼德斯) <gav...@google.com> wrote:

I have been using it daily for debugging for ages.  When did it break for you?  I last pulled to trunk a few days ago and I've done a lot of debugging in it since then.

Please leave it in.  If I see the same problems, I may well go ahead and fix it.  I bet others would do the same.

For some time now, my team has had to hack child_process_sandbox_support_linux.cc locally to get Linux debugging to work (otherwise chrome hangs in gdb).

+bungeman for the fix.

Tom

[John Abd-El-Malek]

On Thu, Apr 5, 2012 at 12:38 PM, Peter Kasting <pkas...@chromium.org> wrote:

On Thu, Apr 5, 2012 at 12:34 PM, John Abd-El-Malek <j...@chromium.org> wrote:

This is used on Android now for WebView.

I think it's time we add automated tests for it though.

Wait, are you saying it's used in some user-exposed fashion?

--single-process is known to be seriously broken in major ways, which would be prohibitive to fix.

Now that it's needed (there's been a long discussion about this, but it was pre-release so it wasn't public), people are working on fixing these issues. i.e. the in process webkit stuff doesn't work, and people are working on implementing indexeddb/domstorage in a way that doesn't need to run webkit a second time on a different thread.

[Peter Kasting]

Wow.  OK.  That's still very scary to me, as the entire core of Chrome was built for many years without making this stuff work correctly.  I understand you're working on the known problems, but I'd still be very afraid of the unknown issues here.  There's a ton of complexity that has never been tested with this.

Good luck, I guess...

PK

[Darin Fisher]

Yeah, like shutdown is not implemented properly at all.  There are a lot of shutdown races which leads to crashes, dead-locks, etc. at shutdown time.  This is probably the hard part of getting single process mode to work properly.

-Darin

 

PK

[Aaron Boodman]

On Thu, Apr 5, 2012 at 1:06 PM, John Abd-El-Malek

What is the state of the world wrt in-process-webkit? The reason this
came up for me was that I was assigned a bug where the utility thread
is crashing in single process mode because it tries to access
webKitPlatformSupport() which is never initialized.

- a

[Darin Fisher]

I thought the utility thread wasn't run in single process mode.  If that has

changed, then a quick fix would be to disable WebKit usage for the utility

thread when we are in single process mode.  Just fail the incoming IPCs.

The rewrite for IDB is forthcoming.  I think the domstorage backend has

already been switched to not use WebKit.

-Darin

[Michael Nordman]

+1 just fail if invoked in single-process

> The rewrite for IDB is forthcoming.  I think the domstorage backend has
> already been switched to not use WebKit.

IDB.next, an impl that doesn't rely on in-process-webkit and
complicated webcore classes in the main browser process, is a ways out
yet. Hasn't been started even, just a twinkle in the eye... but it is
on deck to get underway this quarter. The change to get off of
in-process-webkit for dom_storage is working its way thru the commitQ
now.

[Aaron Boodman]

Here's the bug: crbug.com/122025

Looking at the stack more closely, Darin is right that the
UtilityThread is never created. However code inside webkit/glue
assumes that webKitPlatformSupport is initialized.

- a

[Elliot Poger]

On Thu, Apr 5, 2012 at 3:23 PM, Aaron Boodman <a...@chromium.org> wrote:

The evidence seems to say that it isn't important, since it doesn't
start up reliably anymore (at least on Linux).

Here's the bug tracking that failure, including a workaround patch...

http://crbug.com/123977 ('Debug build of Chromium does not work with --single-process')

[Randy Smith]

Given that we're trying to productize this: I'm running into a problem with --single-process where it appears that lookups of BrowserContexts through RenderViewHostImpl::FromID() can get confused between incognito and non-incognito profiles.  I'm working around the problem (--single_process for the win, but you gotta be careful with that shift key :-}), so it's not a big deal for me.  But if it has larger relevance, I'll put the effort into coming up with a reproducible use case and file a bug.  Is this a known problem that's being worked on (or alternatively, known not to be relevant for the productization effort) or should I try to put together that bug report?

-- Randy

 

 We should never ever be running this outside of debugging.

PK 

[Martin Kosiba]

On May 7, 7:04 pm, Randy Smith <rds...@google.com> wrote:
> On Thu, Apr 5, 2012 at 1:06 PM, John Abd-El-Malek <jabde...@google.com>wrote:
>
>
>
>
>
>
>
>
>
>
>
> > On Thu, Apr 5, 2012 at 12:38 PM, Peter Kasting <pkas...@chromium.org>wrote:
>
> >> On Thu, Apr 5, 2012 at 12:34 PM, John Abd-El-Malek <j...@chromium.org>wrote:
>
> >>> This is used on Android now for WebView.
>
> >>> I think it's time we add automated tests for it though.
>
> >> Wait, are you saying it's used in some user-exposed fashion?
>
> >> --single-process is known to be seriously broken in major ways, which
> >> would be prohibitive to fix.
>
> > Now that it's needed (there's been a long discussion about this, but it
> > was pre-release so it wasn't public), people are working on fixing these
> > issues. i.e. the in process webkit stuff doesn't work, and people are
> > working on implementing indexeddb/domstorage in a way that doesn't need to
> > run webkit a second time on a different thread.
>
> Given that we're trying to productize this: I'm running into a problem with
> --single-process where it appears that lookups of BrowserContexts through
> RenderViewHostImpl::FromID() can get confused between incognito and
> non-incognito profiles.  I'm working around the problem (--single_process
> for the win, but you gotta be careful with that shift key :-}), so it's not
> a big deal for me.  But if it has larger relevance, I'll put the effort
> into coming up with a reproducible use case and file a bug.  Is this a
> known problem that's being worked on (or alternatively, known not to be
> relevant for the productization effort) or should I try to put together
> that bug report?

This is a constraint of the current architecture - there is one
profile per renderer process,
so in single process mode you get only one profile.
I don't think it's worth coming up with a repro or anything - this
seems to be a well-known
issue. Feel free to open a bug for tracking this, though it'll
probably get closed as won't fix.

[Jeff Timanus]

Reviving an old thread.  Is it now time to permanently kill --single-process?  It is totally broken for me in debug as of recent changes.

On windows (svn@151898) and linux (svn@151782), on totally fresh profiles and with no changes present, I get the following assert when navigating away from the new tab page when running --single-process.

[25020:25020:1469260864746:FATAL:frame_navigation_state.cc(198)] Check failed: frame_state_map_.find(frame_id) != frame_state_map_.end(). 

Backtrace:

base::debug::StackTrace::StackTrace() [0x7f3ac8b83736]

logging::LogMessage::~LogMessage() [0x7f3ac8baadd3]

extensions::FrameNavigationState::SetIsServerRedirected() [0x7f3ac72994c5]

extensions::WebNavigationTabObserver::Observe() [0x7f3ac70beb28]

NotificationServiceImpl::Notify() [0x7f3ac7e4c923]

content::(anonymous namespace)::NotifyOnUI<>() [0x7f3ac7eeb261]

base::internal::RunnableAdapter<>::Run() [0x7f3ac7ef8f81]

base::internal::InvokeHelper<>::MakeItSo() [0x7f3ac7ef6bd9]

base::internal::Invoker<>::Run() [0x7f3ac7ef38b5]

base::Callback<>::Run() [0x7f3ac63488a9]

MessageLoop::RunTask() [0x7f3ac8bb0022]

MessageLoop::DeferOrRunPendingTask() [0x7f3ac8bb013a]

MessageLoop::DoWork() [0x7f3ac8bb0955]

base::MessagePumpGlib::HandleDispatch() [0x7f3ac8c33e79]

(anonymous namespace)::WorkSourceDispatch() [0x7f3ac8c33593]

0x7f3ac40c08c2

0x7f3ac40c4748

0x7f3ac40c48fc

base::MessagePumpGlib::RunWithDispatcher() [0x7f3ac8c33b28]

base::MessagePumpGlib::Run() [0x7f3ac8c33f56]

MessageLoop::RunInternal() [0x7f3ac8bafce7]

MessageLoop::RunHandler() [0x7f3ac8bafb9e]

base::RunLoop::Run() [0x7f3ac8bd8f4e]

ChromeBrowserMainParts::MainMessageLoopRun() [0x7f3ac6d4198d]

content::BrowserMainLoop::RunMainMessageLoopParts() [0x7f3ac7d8b1bd]

(anonymous namespace)::BrowserMainRunnerImpl::Run() [0x7f3ac7f8052a]

BrowserMain() [0x7f3aca6c6bf4]

content::RunNamedProcessTypeMain() [0x7f3ac93af18e]

content::ContentMainRunnerImpl::Run() [0x7f3ac93aff18]

content::ContentMain() [0x7f3ac93ae7f5]

ChromeMain [0x7f3ac61ff73d]

main [0x7f3ac61ff6fc]

0x7f3abe44cc4d

0x7f3ac61ff609

Trace/breakpoint trap

Jeff

--
Software Developer
Google Canada
(514) 670-8756

[Dana Jansens]

Should we have at least one bot for --single-process if we want to
maintain it at all?

[John Abd-El-Malek]

regarding killing it: no, per all the other emails on this subject

regarding bot: it seems the quickest thing would be to add a browser_tests that adds the --single-process flag and checks a simple page loads. i'm wary of adding yet another bot that runs through all the browser_tests in single process mode because that effectively doubles the number of tests we run.

[Samuel]

Looks --single-process is broken recently.  I searched crbug, found a related open ticket http://code.google.com/p/chromium/issues/detail?id=164330
Just confirm I observed same issue from 7/Dec 25.0.1349.2 build, no matter release or debug build. content_shell is fine.

BTW, #164330 is not confirmed yet, although it does exist.

Samuel