Corrected title to reflect that this actually takes close to 50s the first time. Second attempt takes only a second or two.

While things are in this state opening up CrOSH is also slow to respond; tab opens but the shell takes ~5-10s to show a prompt.

+oshima, who IIRC was worried about futex() calls.

This same kind of hang seems to affect Send Feedback on this device, FWIW.

There was a issue in kernel which can cause issue like this, which was reverted in crbug.com/603594. Please let me know if you still have a issue with that change.

Thanks oshima@ - which ChromeOS platform revision will that be in?

=> ned to triage

50 stable, but I'm not sure if we did revert on m51. marcheu@ ?

According to #2, I am suspecting that this has something to do with the whole browser? More specifically, instead of opening "about:tracing", opening any other link will also  has the same problem?

wez@, can you reproduce the same scenario but instead of "chrome:tracing", you open another chrome page like "chrome:version"?

Re #6: No, in general the device works fine; this was specifically a problem with hitting the Record button in chrome://tracing, and there was a similar effect with Send Feedback from the hotdog menu.

I believe the kernel issue oshima@ refers to fits the bill as most likely culprit.

wez@ are you still having this?

Yes, still repros with 52.0.2717.5 / 8249.2.0 on Panther.

Can you open another chrome://tracing and trace the trace?

Re #10: No. Opening a second chrome://tracing and hitting Record while waiting for the recording dialog to show in the first chrome://tracing gives an error:

Error while recording
Error: Error occured at /json/categories
    at chrome://tracing/tracing.js:927:255

Can you start the first one, then start second, and see if the error message also takes time or it shows up immediately?

Error message showed up immediately; first tab was still waiting for the
dialog to show.

If the second one can respond to the recording request immediately, sounds like the issue is in tracing side.

nduca@, can you find a right owner for this?

wez@, can you file a feedback and post the link here?

I loaded up chrome://tracing and hit Record and then submitted a feedback, mentioning this bug in the description.

However, I've been waiting several minutes now and there's still no sign of the recording settings dialog, so things may be more fundamentally broken.

It's been about half an hour now, and the chrome://tracing recording settings dialog still hasn't appeared.

I reloaded the tab and now it repeatedly and immediately gives the error message.

I tried to Report an issue.. but now that doesn't do anything either - maybe blocked by whatever hung process is blocking the Record button?

+afakhry@ for feedback report issue.

Does chrome://tracing communicate with debugd?

according to  crbug.com/613122 , it looks like it communicates with some cros processes at least.

djkurtz@, do you know who is familiar with the traching <-> cros process interaction?

djkurtz@ found that it indeed communicates with debugd. 

wez@, can you try without system tracing and see if that fixes the issue?

Opening chrome://tracing with performance tracing disabled, it is almost
instantaneous to show the dialog.

Sorry, which tracing is it? Are you talking about categories that are disabled by default?

Buy the way, chrome crashed if I enabled them :(. I'll file a separate bug.

Filed  crbug.com/613636 . memory-infra was causing my crash. wez@, what if you disable this one?

Is this a sup of  issue 613122 ?

dup*

It may be related, but this it started before 613122.

oshima: This bug is about the Record dialog taking ~50s to appear - I can't disable/enable any of the logging options because the dialog itself hasn't even appeared.

When you asked me to disable system tracing I assumed you meant to disable performance tracing, which I did have enabled on this device.

Ok, I don't know what performance tracing is then. Where can I enable/disable it?

Ok, it's chrome://slow, which enables TracingManager in components/feedback.

zork@, can you look into this or find the right owner for this?

To add a bit more data:

I tried on:
  Hardware: oak
  Chrome:	52.0.2717.5
  CROS:	8249.2.0

(1) Navigate to chrome://slow
(2) "Enable performance data collection"
(3) Navigate to chrome://tracing
(4) Click Record

The first time it takes ~4 seconds for the "Record a new trace..." dialog to appear.
The second time the "Record a new trace..." dialog appears instantaneously.

This repeats if chrome://slow is disabled & enabled.

  Hardware: samus
  Chrome:   50.0.2661.104
  CROS:     7978.76.0

(1) Navigate to chrome://slow
(2) "Enable performance data collection"
(3) Navigate to chrome://tracing
(4) Click Record

The first time it takes ~2 seconds for the "Record a new trace..." dialog to appear.
The second time the "Record a new trace..." dialog appears instantaneously.

This repeats if chrome://slow is disabled & enabled.

FWIW I've started getting excessively long delays, and crashes, after pressing Record even without performance data collection enabled; filed  issue 675269  for that.

Ehm this bug is about Chrome M50-52 which are bot prehistory. Stable is M55 today.
Can somebody confirm this is an issue at all these days?

Re #34: Yup, I bumped this bug (comment #32) specifically because I'm observing it now, on my Chromebox.

Closing this out as Fixed, to track the new chrome://tracing regression & crashiness on  issue 675269 .