Dropping --single-process support (on Mac, or everywhere?)

[Elly Fong-Jones]

Hi folks!

As you probably know if you work on macOS, --single-process fails a CHECK at startup on macOS and has not worked for quite a while (I think at least a year). Does anyone actually depend on this switch & behavior? Would anyone be sad if we removed it?

-- elly

[Ken Rockot]

On Wed, Mar 17, 2021 at 10:15 AM Elly Fong-Jones <elly...@chromium.org> wrote:

Hi folks!

As you probably know if you work on macOS, --single-process fails a CHECK at startup on macOS and has not worked for quite a while (I think at least a year). Does anyone actually depend on this switch & behavior? Would anyone be sad if we removed it?

IIRC there are quite a few browser tests which depend on the switch. They would have to be rewritten or we'd lose test coverage.

Is the CHECK on macOS not possible to fix?

 

-- elly

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/29e94d02-a8d7-4e69-8c47-95390fb3f19cn%40chromium.org.

[Xianzhu Wang]

I would like to keep it for content_shell. I'm using it almost every day on Linux to debug content_shell in gdb. It has a DCHECK failure on Linux during shutdown, but I can live with it.

Might be fine to remove it for Chrome?

--

[Elly Fong-Jones]

On Wed, Mar 17, 2021 at 10:21 AM Ken Rockot <roc...@google.com> wrote:

On Wed, Mar 17, 2021 at 10:15 AM Elly Fong-Jones <elly...@chromium.org> wrote:

Hi folks!

As you probably know if you work on macOS, --single-process fails a CHECK at startup on macOS and has not worked for quite a while (I think at least a year). Does anyone actually depend on this switch & behavior? Would anyone be sad if we removed it?

IIRC there are quite a few browser tests which depend on the switch. They would have to be rewritten or we'd lose test coverage.

These must be not running on Mac, or somehow avoiding the CHECK in question, which happens at browser startup.

 

Is the CHECK on macOS not possible to fix?

It's very likely to be fixable, although I couldn't guess how much effort it would be. This question originally arose because it had been broken so thoroughly and for so long that we thought that nobody could possibly be relying on it.

  

-- elly

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/29e94d02-a8d7-4e69-8c47-95390fb3f19cn%40chromium.org.

-- elly 

[Rik Cabanier]

We often use it to simplify debugging on Android. It would be unfortunate if the flag was removed.

[Dave Tapuska]

Here is some test code that enforces it:

https://source.chromium.org/chromium/chromium/src/+/master:content/public/test/browser_test_base.cc;l=869;drc=e6ae3b112e62e356133539114a1d78ce2c229dd4;bpv=1;bpt=1

I personally find tests that do this frustrating to fix because they don't test the real world situations.

dave.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAGN7qDCgQ801aPd7Y8yLuHkojpA2gb-HKc0uoi-8dXbqM87Cuw%40mail.gmail.com.

[Olivier Li]

I also personally use it as part of my gdb debugging scripts. (Linux)

If the engineering effort to fix the CHECK is insurmountable  and the flag is removed it will not keep me from working completely but it would reduce my efficiency diagnosing some stability problems.

Are you aware if there are other ways to achieve easy debugging of browser tests for example?

[Scott Violet]

+1 to what Xianzhu says. I'll say it slightly differently, removing --single-process for blink debugging via content_shell would impact productivity.

  -Scott

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CADBxrieRUMQciJ5k-yHpyj5-WgbDObhyfvPMU1GNFnDxxVnL2A%40mail.gmail.com.

[Ian Kilpatrick]

Somewhat piling on at this point - but I use --single-process everyday on MacOS and this would affect productivity.

Ian

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAKARY_n-MAMxEWEkqLfMinkTycLVe8vXMo4uik3CZvBB5DCp1w%40mail.gmail.com.

[Michael Lippautz]

+1 to the use case for Blink debugging with content_shell, where it boosts my productivity in debugging memory issues.

-Michael

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAJL3UpQQpgwHgVD2sZ2uepshjp4MyRckCExrUOzYhhKjR_9WXQ%40mail.gmail.com.

[Torne (Richard Coles)]

The Android WebView uses single-process mode in production on older OS versions and internally sets the --single-process flag here: https://source.chromium.org/chromium/chromium/src/+/master:content/browser/android/content_startup_flags.cc

I don't have an opinion on whether it needs to be allowed on other platforms or not, but it cannot be removed/broken for OS_ANDROID.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAJL3UpQQpgwHgVD2sZ2uepshjp4MyRckCExrUOzYhhKjR_9WXQ%40mail.gmail.com.

[Elly Fong-Jones]

Alright, thanks folks - we will not go ahead with deleting the switch :P I'll try to make some time to dig into why it fails a CHECK.

-- elly

[Ian Kilpatrick]

Angry racoons disperse! [*] :P 

[*] https://twitter.com/laparisa/status/1364747468278145026

(thanks elly).

[Stefan Zager]

For the record: I'm a bit disappointed to hear from so many senior engineers who use --single-process for debugging. I used to do that, but I got burned one too many times. Now, I am very comfortable debugging multi-process chrome and content_shell, including on Android. I do not find it to be a productivity drag whatsoever -- on the contrary.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAJL3UpQzByp4akE3Ny3VeP54PTHN7DXSh76nu0wZfptQU%3DPvGQ%40mail.gmail.com.

[Daniel Cheng]

It's a matter of convenience. The last I checked, debugging child processes outside of Windows is still a bit painful.

FWIW, I often don't bother with --single-process or debuggers; I often resort to LOG(ERROR) :P

Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHOQ7J93BR4aKEm8wChm9XvSRWP4r0W-OzqVXggRwfiov9k7DA%40mail.gmail.com.

[Stefan Zager]

On Wed, Mar 17, 2021 at 12:21 PM Daniel Cheng <dch...@chromium.org> wrote:

It's a matter of convenience. The last I checked, debugging child processes outside of Windows is still a bit painful.

I debug primarily on Linux, and I don't find it to be painful at all.

[Xianzhu Wang]

I think this depends on scenarios. There are scenarios (e.g. oopif) where --single-process has problems, but it is suitable for most of my scenarios and I have never encountered any problem. For scenarios where --single-process is not suitable, I will use LOG(ERROR) and base::debug::StackTrace().Print().

[Daniel Cheng]

Is there a better / more automated way to do this than --renderer-startup-dialog + --no-sandbox? I particularly don't enjoy running with the second flag :)

Daniel

[Stefan Zager]

On Wed, Mar 17, 2021 at 1:25 PM Xianzhu Wang <wangx...@chromium.org> wrote:

I think this depends on scenarios. There are scenarios (e.g. oopif) where --single-process has problems, but it is suitable for most of my scenarios and I have never encountered any problem. For scenarios where --single-process is not suitable, I will use LOG(ERROR) and base::debug::StackTrace().Print().

Mentioning OOPIF in connection with --single-process is a sure way to get my hackles up :)

I have spent a *lot* of time debugging OOPIF issues which disappear when you use --single-process. How can you debug an IPC race condition in --single-process?

--single-process, much like csh, is outdated and considered harmful.

[Stefan Zager]

On Wed, Mar 17, 2021 at 1:34 PM Daniel Cheng <dch...@chromium.org> wrote:

Is there a better / more automated way to do this than --renderer-startup-dialog + --no-sandbox? I particularly don't enjoy running with the second flag :)

"Enjoy" is maybe not so relevant. If it's the typing that offends you, I recommend an alias, bash function, or script. That's what I do.

[Stefan Zager]

But to your point: if you need to debug something that happens during startup, then --renderer-startup-dialog works for me. Otherwise, I just attach to the running process.

[Jeremy Roman]

On Wed, Mar 17, 2021 at 4:40 PM 'Stefan Zager' via Chromium-dev <chromi...@chromium.org> wrote:

But to your point: if you need to debug something that happens during startup, then --renderer-startup-dialog works for me. Otherwise, I just attach to the running process.

On Wed, Mar 17, 2021 at 1:37 PM Stefan Zager <sza...@google.com> wrote:

On Wed, Mar 17, 2021 at 1:34 PM Daniel Cheng <dch...@chromium.org> wrote:

Is there a better / more automated way to do this than --renderer-startup-dialog + --no-sandbox? I particularly don't enjoy running with the second flag :)

"Enjoy" is maybe not so relevant. If it's the typing that offends you, I recommend an alias, bash function, or script. That's what I do.

I assumed he was worried about turning off the sandbox. But of course in single-process mode, there is also no sandbox. :)

 

Daniel

On Wed, Mar 17, 2021 at 12:23 PM Stefan Zager <sza...@google.com> wrote:

On Wed, Mar 17, 2021 at 12:21 PM Daniel Cheng <dch...@chromium.org> wrote:

It's a matter of convenience. The last I checked, debugging child processes outside of Windows is still a bit painful.

I debug primarily on Linux, and I don't find it to be painful at all.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHOQ7J_CZyCAstg%3Dot%2BSH9geDg2FExsO%3DRFBDpbnSzXHqB1pUw%40mail.gmail.com.

[Xianzhu Wang]

On Wed, Mar 17, 2021 at 1:36 PM Stefan Zager <sza...@google.com> wrote:

On Wed, Mar 17, 2021 at 1:25 PM Xianzhu Wang <wangx...@chromium.org> wrote:

I think this depends on scenarios. There are scenarios (e.g. oopif) where --single-process has problems, but it is suitable for most of my scenarios and I have never encountered any problem. For scenarios where --single-process is not suitable, I will use LOG(ERROR) and base::debug::StackTrace().Print().

Mentioning OOPIF in connection with --single-process is a sure way to get my hackles up :)

I have spent a *lot* of time debugging OOPIF issues which disappear when you use --single-process. How can you debug an IPC race condition in --single-process?

Definitely I can't and won't use --single-process to debug OOPIF issues or IPC race conditions. However, --single-process is simply more convenient for scenarios where it doesn't have problems. In most cases, it's easy to rule out OOPIF/IPC issues before starting debugging an issue.

[Stefan Zager]

On Wed, Mar 17, 2021 at 2:06 PM Xianzhu Wang <wangx...@chromium.org> wrote:

On Wed, Mar 17, 2021 at 1:36 PM Stefan Zager <sza...@google.com> wrote:

On Wed, Mar 17, 2021 at 1:25 PM Xianzhu Wang <wangx...@chromium.org> wrote:

I think this depends on scenarios. There are scenarios (e.g. oopif) where --single-process has problems, but it is suitable for most of my scenarios and I have never encountered any problem. For scenarios where --single-process is not suitable, I will use LOG(ERROR) and base::debug::StackTrace().Print().

Mentioning OOPIF in connection with --single-process is a sure way to get my hackles up :)

I have spent a *lot* of time debugging OOPIF issues which disappear when you use --single-process. How can you debug an IPC race condition in --single-process?

Definitely I can't and won't use --single-process to debug OOPIF issues or IPC race conditions. However, --single-process is simply more convenient for scenarios where it doesn't have problems. In most cases, it's easy to rule out OOPIF/IPC issues before starting debugging an issue.

Ah, but can you rule out font loading issues?

[Xianzhu Wang]

I'm not sure because I don't have experience in this. I would try another debugging method (LOG, etc.) if the issue couldn't reproduce in gdb, which happens often due to flakiness related to timing.

I would prefer LOG (or rr) to gdb on a live process for multi-process issues because 1) such issues are often flaky 2) the pause in gdb may break the condition of the issue 3) I'm too lazy to issue the gdb attach command :)

 

[K. Moon]

My general thought on workflow (whether it comes to debugging or anything else): Developers should do whatever works for them.

If what works for them is bad in some way, maybe it'll eventually stop working and they'll have to pay the switching cost. Otherwise, the new way should be sufficiently better than the old way that you don't need to argue with people to do it the new way.

So marketing the new way is good, but arguing against the old way is often counter-productive. :-)

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CADBxricZrF0gVJZhi7iCY4zy3tcMw-2Qyt_BcmO3PG-HwmUe%3Dg%40mail.gmail.com.

[Leszek Swirski]

For people wanting to gdb in multiple processes, I've also had a lot of success with setting gdb to following forks without detaching on fork, and using its non-stop mode to allow other threads to run. I use this magic incantation (that I've saved in a gdb wrapper script):

set follow-fork-mode parent

set detach-on-fork off

set non-stop on

set target-async on

set schedule-multiple on

set print inferior-events off

set print thread-events off

set print symbol-loading off

set pagination off

handle SIGSYS nostop noprint

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Christian Biesinger]

I use this switch a lot (mostly in content shell). It makes debugging
a lot easier. Please do not remove it on Linux.


Christian

On Wed, Mar 17, 2021 at 6:16 PM Elly Fong-Jones <elly...@chromium.org> wrote:
>
> Hi folks!
>
> As you probably know if you work on macOS, --single-process fails a CHECK at startup on macOS and has not worked for quite a while (I think at least a year). Does anyone actually depend on this switch & behavior? Would anyone be sad if we removed it?
>
> -- elly
>

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---
> You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/29e94d02-a8d7-4e69-8c47-95390fb3f19cn%40chromium.org.

[Nico Weber]

Please put recommendations like this in https://chromium.googlesource.com/chromium/src/+/0e94f26e8/docs/linux_debugging.md :)

I agree with everyone on this thread:

- --single-process is convenient but you have to be aware of the downsides

- debugging without it isn't so bad if you know how, and that way you debug the real config

- people should use what works for them, but we should make sure the recommended way is well-documented and as easy to use as possible

- multiprocess debugging _does_ need a bit more setup than single process debugging

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CADBxricZrF0gVJZhi7iCY4zy3tcMw-2Qyt_BcmO3PG-HwmUe%3Dg%40mail.gmail.com.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/7f7a637f-d72b-4ade-9a34-ed2e224bcfb4n%40chromium.org.

[John Abd-El-Malek]

+1.

There are cases where you wouldn't want to use it (anything where multiple renderers are involved, or sandboxing etc...). But for "common" cases it's a time saver. There are tests in content_browsertests and browser_tests to ensure it works. The latter didn't work on Mac (originally a crash in  cc::SingleThreadProxy::SetNeedsCommit, not sure if that's what you're seeing now Elly?) so the test was skipped there.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGbLiFCfwTFg3BTiX7cU14L1A86pnf5Nn4mkDx0TdH8FaMymw%40mail.gmail.com.

[Stefan Zager]

I'll just say a few final words and then slink back to my cave...

Maintaining --single-process is itself a tax on productivity and a pile of (IMO needless) complexity in the code base. The only justification for it is "developer convenience" in debugging, and I'm using scare quotes there advisedly because, as I have made clear, I think the "convenience" is largely illusory. I suspect that a lot of chromium developers use --single-process because, somewhere along the line, either they read about it in a doc, or someone advised them to do so. If, instead, developers were advised to debug multi-process chrome; and if the instructions for doing so were front and center in our documentation; then a lot more developers would use it, without any grumbling about convenience. It's just not that hard.

[John Abd-El-Malek]

If anyone has data to share that this has been expensive to maintain it would be helpful in evaluating vs its helpfulness. Like Torne mentioned, we do need single process for webview versions so content and below already have to support this mode. The question is whether chrome/ and the components/ that aren't on webview are paying extra support cost that isn't warranted. My experience has been that this is transparent to most features, but happy to be shown otherwise.

[Torne (Richard Coles)]

At least for things that directly check the flag there are only a single-digit number of cases outside of base, content, android_webview, and tests, and one of those is for the infobar in chrome that tells you not to: https://source.chromium.org/search?q=kSingleProcess%20-f:content%20-f:android_webview%20-f:base%20-f:test&ss=chromium

[dan...@chromium.org]

On Thu, Mar 18, 2021 at 4:28 PM 'Stefan Zager' via Chromium-dev <chromi...@chromium.org> wrote:

I'll just say a few final words and then slink back to my cave...

Maintaining --single-process is itself a tax on productivity and a pile of (IMO needless) complexity in the code base. The only justification for it is "developer convenience" in debugging

I shall throw out there that CEF (Chromium Embedded Framework) exposes single process as an option, and the overhead and forced asynchronicity (the App can talk synchronously to the renderer on its thread) would break a lot of apps. Getting rid of this mode would pin a lot of CEF users at an old Chrome.

Not that we make product decisions around this, just to say I know this goes beyond debugging and tests (which are single process for the same reasons as these CEF apps really, plus the ability to inject C++ into the renderer process in tests).

Nothing is unsolvable everything is code but I think single-process is a pretty small burden to carry forward compared to alternatives.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHOQ7J_dhd9HG-kbUqdb1HOP71Q%2BDoo%2BaV0tZYdFdZ4zc52h3Q%40mail.gmail.com.

[Marshall Greenblatt]

On Thu, Mar 18, 2021 at 5:25 PM <dan...@chromium.org> wrote:

On Thu, Mar 18, 2021 at 4:28 PM 'Stefan Zager' via Chromium-dev <chromi...@chromium.org> wrote:

I'll just say a few final words and then slink back to my cave...

Maintaining --single-process is itself a tax on productivity and a pile of (IMO needless) complexity in the code base. The only justification for it is "developer convenience" in debugging

I shall throw out there that CEF (Chromium Embedded Framework) exposes single process as an option, and the overhead and forced asynchronicity (the App can talk synchronously to the renderer on its thread) would break a lot of apps. Getting rid of this mode would pin a lot of CEF users at an old Chrome.

Not that we make product decisions around this, just to say I know this goes beyond debugging and tests (which are single process for the same reasons as these CEF apps really, plus the ability to inject C++ into the renderer process in tests).

CEF dropped official support for single-process mode back in 2013. We've left the option for debugging purposes, but it's not recommended for many of the reasons discussed in this thread (flakyness, shutdown crashes, etc). Most companies have probably migrated to multi-process mode by now, or have stuck with an older Chromium version for other reasons (like Windows XP support).

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHtyhaRsmRpM4Uqv8Gj77tZaj%2B46bwjAF16hApBKrOTEsMoy-A%40mail.gmail.com.