Do you use --wait-for-debugger[-children] or --debug-on-start?

[Peter Kasting]

Please let me know if you use --wait-for-debugger, --wait-for-debugger-children, or --debug-on-start in your Chrome debugging, how often, and whether you're aware of any satisfactory alternatives.

If these are used rarely or never, and/or we can replace their usage with other existing flags, they will be removed.  I'll wait up to a week or so for answers.

PK

[Brett Wilson]

I use these like once a year or two, but when you need to debug child
process startup, it's the only thing I'm aware of on Windows that
works.

Brett

[Scott Graham]

Yes, I use --wait* ones when using VS to debug.

windbg -o is the only alternative I'm aware of.

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

[Antoine Labour]

On Fri, Mar 28, 2014 at 1:06 PM, Peter Kasting <pkas...@google.com> wrote:

Please let me know if you use --wait-for-debugger, --wait-for-debugger-children, or --debug-on-start in your Chrome debugging, how often, and whether you're aware of any satisfactory alternatives.

I use --*-startup-dialog instead. Are there differences? Seems like redundancy.

Antoine

 

If these are used rarely or never, and/or we can replace their usage with other existing flags, they will be removed.  I'll wait up to a week or so for answers.

PK

--

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

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

[Scott Graham]

startup-dialog is useful, but requires the sandbox to be off on Windows.

[Peter Kasting]

On Fri, Mar 28, 2014 at 2:40 PM, Scott Graham <sco...@chromium.org> wrote:

On Fri, Mar 28, 2014 at 2:38 PM, Antoine Labour <pi...@google.com> wrote:

I use --*-startup-dialog instead. Are there differences? Seems like redundancy.

 

startup-dialog is useful, but requires the sandbox to be off on Windows.

Then could we replace the four --xxx-startup-dialog flags with --wait-for-debugger[-children]?  That would at least get us from two sets of these flags to one.

No one has mentioned --debug-on-start yet, which is good, since I don't even know what it does.

PK

[Antoine Labour]

On Fri, Mar 28, 2014 at 2:42 PM, Peter Kasting <pkas...@google.com> wrote:

On Fri, Mar 28, 2014 at 2:40 PM, Scott Graham <sco...@chromium.org> wrote:

On Fri, Mar 28, 2014 at 2:38 PM, Antoine Labour <pi...@google.com> wrote:

I use --*-startup-dialog instead. Are there differences? Seems like redundancy.

 

startup-dialog is useful, but requires the sandbox to be off on Windows. 

Then could we replace the four --xxx-startup-dialog flags with --wait-for-debugger[-children]?  That would at least get us from two sets of these flags to one.

I kinda like the flexibility of selecting which process I'm trying to debug, otherwise it gets tedious to manually attach the debugger on every single sub-process created (I mostly use gdb). Tradeoff may be different on windows?

Antoine

[Zachary Turner]

Funny timing on this thread.  I just finished implementing automatically attach to child processes in VsChromium.  I was going to post here after I pushed it up to GitHub, but this seems like a reasonable thread to mention it in.  It has a couple advantages over the existing command line flags:

1) It doesn't require --no-sandbox.

2) It will allow you to set a breakpoint *much* earlier in the startup, even in the main() function.

3) It's more convenient than having 100 dialogs pop up when you start chrome.

There is one limitation: It doesn't work if you start Visual Studio via F5.  It only works if you attach to process.  However, it's not a big limitation, because it will then successfully attach to all future child processes that spawn, so you can still catch renderer startup for future renderers, just not the initial ones that spawn when you hit F5.  I plan to add F5 support next, but it's not as simple as it seems.  

--

[Peter Kasting]

On Fri, Mar 28, 2014 at 2:45 PM, Antoine Labour <pi...@google.com> wrote:

On Fri, Mar 28, 2014 at 2:42 PM, Peter Kasting <pkas...@google.com> wrote:

On Fri, Mar 28, 2014 at 2:40 PM, Scott Graham <sco...@chromium.org> wrote:

On Fri, Mar 28, 2014 at 2:38 PM, Antoine Labour <pi...@google.com> wrote:

I use --*-startup-dialog instead. Are there differences? Seems like redundancy.

 

startup-dialog is useful, but requires the sandbox to be off on Windows. 

Then could we replace the four --xxx-startup-dialog flags with --wait-for-debugger[-children]?  That would at least get us from two sets of these flags to one.

I kinda like the flexibility of selecting which process I'm trying to debug, otherwise it gets tedious to manually attach the debugger on every single sub-process created (I mostly use gdb). Tradeoff may be different on windows?

I assumed there was some way to selectively pass the flag to the process you wanted a la "--plugin-args=--wait-for-debugger" or something.  But maybe such a thing doesn't exist, or that isn't the problem you were describing.

PK

[John Abd-El-Malek]

On Fri, Mar 28, 2014 at 2:42 PM, Peter Kasting <pkas...@google.com> wrote:

On Fri, Mar 28, 2014 at 2:40 PM, Scott Graham <sco...@chromium.org> wrote:

On Fri, Mar 28, 2014 at 2:38 PM, Antoine Labour <pi...@google.com> wrote:

I use --*-startup-dialog instead. Are there differences? Seems like redundancy.

 

startup-dialog is useful, but requires the sandbox to be off on Windows.

Then could we replace the four --xxx-startup-dialog flags with --wait-for-debugger[-children]?  That would at least get us from two sets of these flags to one.

I use startup-dialog all the time; keep as is.

 

No one has mentioned --debug-on-start yet, which is good, since I don't even know what it does.

PK

--

[Antoine Labour]

Yeah, I think that would work, but I don't think we have such a thing today.

Antoine

PK

[Peter Kasting]

On Fri, Mar 28, 2014 at 2:53 PM, John Abd-El-Malek <j...@chromium.org> wrote:

On Fri, Mar 28, 2014 at 2:42 PM, Peter Kasting <pkas...@google.com> wrote:

On Fri, Mar 28, 2014 at 2:40 PM, Scott Graham <sco...@chromium.org> wrote:

On Fri, Mar 28, 2014 at 2:38 PM, Antoine Labour <pi...@google.com> wrote:

I use --*-startup-dialog instead. Are there differences? Seems like redundancy.

 

startup-dialog is useful, but requires the sandbox to be off on Windows.

Then could we replace the four --xxx-startup-dialog flags with --wait-for-debugger[-children]?  That would at least get us from two sets of these flags to one.

I use startup-dialog all the time; keep as is.

Well, we may have to, if there are no options that satisfy all of "works across OSes", "usable with the sandbox", "usable without a custom build", and "does not require you to connect to every single spawned process.  But it would have been more helpful if you noted why your usage cannot be satisfied by another solution, the way e.g. Antoine did.  That way if someone comes up with something that addresses that use case, we'll know it's a legitimate replacement candidate.

PK 

[Zachary Turner]

Just curious, what's the problem with connecting to every single spawned process?

--

[Peter Kasting]

On Fri, Mar 28, 2014 at 2:59 PM, Zachary Turner <ztu...@chromium.org> wrote:

Just curious, what's the problem with connecting to every single spawned process?

From Antoine: "...it gets tedious to manually attach the debugger on every single sub-process created (I mostly use gdb)."  I assume that, if you just wanted to debug one sub-process, but your repro case ends up creating 20 over time, that means that 19 times you have to manually attach a debugger in order to proceed, which certainly sounds annoying.

PK

[John Abd-El-Malek]

Honestly, this is such a small amount of code, that a conversation about it is not worthwhile IMO. That's why I was terse. Note that of course I'm just referring to this flag; other work on removing unused flags is great.

 

PK 

[Zachary Turner]

Ahh, makes sense.  My solution only addresses Windows users, but all the attachments happen transparently and without requiring user interaction, so I assume there's no issue there. I don't ever debug on non-Windows systems so I'm not sure what the debugging situation is like there, but if any of these flags turn out to be only useful on Windows then I'm happy accomodate those use cases in VsChromium.

[Daniel Cheng]

I use --renderer-startup-dialog all the time to debug layout tests. It's convenient for me because it dumps the renderer PID to stdout and I can easily attach gdb.

Daniel

--

[Dirk Pranke]

Personally I'm w/ Peter on this ... "a small amount of code" is how we ended up w > 1,000 command line flags for debugging in the first place. 

Explaining how this flag was different from the others, why you needed it, and/or why you use this one rather than one of the others, doesn't seem like a big ask from you and would've been illuminating to the rest of us.

-- Dirk

[John Abd-El-Malek]

Most of the ~1000 flags are not for debugging, but for turning on not-enabled-by-default features, or disabling features. Multi-proc type debugging flags that Peter mentioned in the original email are a very small number, and most of them have been around 5+ years (i.e. these are not the ones that keep increasing). Since Peter asked for which ones people still use, my reply was answering that.

In general, since I'm overloaded by emails, sometimes I'm terse only because I think a short email is better than none.

[Dominic Cooney]

I also use --renderer-startup-dialog all the time and would be mildly blue if it went away. I don't begrudge Windows people who need exotic startup flags to debug exotic startup issues; in fact I thank all that is good that I don't have to do what they do.

[Peter Kasting]

To summarize where this thread is:

--*-startup-dialog are widely used.  They can't be replaced by --wait-for-debugger* because there's no easy way to send that flag to only the processes you want, and sending it to all processes forces you to connect a debugger to everything.

--wait-for-debugger* are also used to debug process-startup issues.  They can't be replaced by --*-startup-dialog because that requires the sandbox to be off, which blocks e.g. debugging sandbox startup issues.

--debug-on-start has not been mentioned as in-use by anyone.

Unless further replies indicate usage of --debug-on-start, I will remove that flag and leave the others.

If someone feels inspired, they're welcome to figure out and implement some solution to the problems above that prevent us from having a single, consistent way to debug all process-specific and process-startup issues.  However, that is out of scope for me -- I'm just trying to nail down flag usage and ownership.

PK

[Sam Clegg]

Sorry the late reply. The Visual Studio Add-In for NaCl passes
--wait-for-debugger-children when launching chrome with the intention
of attaching the visual studio debugger to it. Having said that, I
think its been broken for a while and I've been meaning to investigate
why.

[Peter Kasting]

I have now marked --wait-for-debugger[-children] as "Keep" in the flags doc and --debug-on-start as "To Remove", with a bug filed against myself to do so.  --*-startup-dialog were all marked as "Keep" already.

Thanks everyone for your input.

PK