Bug triage report.

[Bence Béky]

Triaged from https://crbug.com/484747 to https://crbug.com/485665.
The triage instructions are very nice, making the rotation clear
(albeit not painless, not by fault of the instructions but by nature
and flux of incoming issues). Kudos to Matt and everybody else in
`git log -- net/docs`.

These five issues I just have no idea what to do with, sorry. I'm
kindly asking the next triager to deal with them. Thank you, Raman.
I'll check back on them to see and learn.

https://crbug.com/388457
https://crbug.com/458620
https://crbug.com/485278
https://crbug.com/485301
https://crbug.com/485345

Handled a couple of other Cr-Internals-Network and other bugs, nothing
extraordinary. Note that a mass removal of a former team member from
cc pushed a lot of stale bugs on the top of the list when ordered by
last modified.

Also filed one bug for a Gasper alert, and rejected eight alerts.
Identified no crashers.

[Raman Tenneti]

Triag'ed up to https://crbug.com/487506

Couple of users complaining about unable to access sites. Requested net-internals logs because we couldn't duplicate.

Nothing extraordinary.

thanks

raman

[Chris Bentzel]

Are there consistent sites they are unable to access, or is this a grab bag?

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMCi4JuwhNbZsRvWT-%3DHpN0tbmsafp3CztZVoeWXn-0B3wcfgQ%40mail.gmail.com.

[Raman Tenneti]

On Wed, May 13, 2015 at 5:15 AM, Chris Bentzel <cben...@chromium.org> wrote:

Are there consistent sites they are unable to access, or is this a grab bag?

The following are the bugs (one user bug report for mint.com). 

Another user said "Play Music" was working again (but ianswett has found the root cause).

https://crbug.com/486071 - Unable to login to mint.com from Chrome -  net-internals was just uploaded by the user

https://crbug.com/485947 - Unable to download files using FTP (I wasn't able to duplicate it).

https://crbug.com/451977 - Unable to click through website slideshows on ComputerWorld, InfoWorld and NetworkWorld websites. (works for me on windows stable channel)

https://crbug.com/486002 - Unable to play music from Play Music (user said it worked again).

thanks

raman

[Elly Jones]

Triage report for 2015-05-12 and 2015-05-13: 

No new network crashes. https://crbug.com/474720 is about 3% of browser crashes on canary still.

Notable new bugs:

https://crbug.com/487659 - we are mishandling Content-Disposition encodings in some way, assigned to asanka@

https://crbug.com/467702 - XHR readyState vs half-closed SPDY stream, working with reporter

https://crbug.com/487687 - crash in the WebSocket JS bindings, requested feedback

I also dug through untriaged Cr-Internals-Network bugs and routed or closed a bunch of them; we are down from 57 to 43 of those bugs. A lot of the remaining ones are either vague "we should do X" (removing global state from net, removing APIs from UDPSocket or jank bugs.

Does anyone know how to deal with the jank bugs? Is there a tool for seeing where jank is and measuring it, or a dashboard people are looking at?

-- elly

[Eric Roman]

On Thu, May 14, 2015 at 7:00 AM, 'Elly Jones' via net-dev <net...@chromium.org> wrote:

Triage report for 2015-05-12 and 2015-05-13: 

No new network crashes. https://crbug.com/474720 is about 3% of browser crashes on canary still.

Notable new bugs:

https://crbug.com/487659 - we are mishandling Content-Disposition encodings in some way, assigned to asanka@

https://crbug.com/467702 - XHR readyState vs half-closed SPDY stream, working with reporter

https://crbug.com/487687 - crash in the WebSocket JS bindings, requested feedback

I also dug through untriaged Cr-Internals-Network bugs and routed or closed a bunch of them; we are down from 57 to 43 of those bugs. A lot of the remaining ones are either vague "we should do X" (removing global state from net, removing APIs from UDPSocket or jank bugs.

Does anyone know how to deal with the jank bugs? Is there a tool for seeing where jank is and measuring it, or a dashboard people are looking at?

Feel free to chat with me about this, I have investigated some of these.

(1) The dashboard (google-internal) is: https://goto.google.com/gptdb

When you load this up, you generally want to limit the data to the latest Windows Canary, and set the Exec thread to Chrome_IOThread

(2) For examples of how to add instrumentation for jank in the code, see the reviews in:

https://code.google.com/p/chromium/issues/detail?id=455942

(3) When reading the jank results, also note that the ScopedTracker subtracts from its parents. In other words if you have one ScopedTracker that outlives another scoped tracker, the outter scoped tracker will not contain any of the time "consumed" by the inner one. Convenient when zeroing in on janky tasks, but was very confusing to me until I realized that is what it did.

 

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

[David Benjamin]

Triage report for 2015-05-18 and 2015-05-19:

Triaged up to 489897.

Notable new bugs:

https://crbug.com/488043 - A fantastic bug about SSL certificate click-throughs and the socket pool. The net-internals log is fun to puzzle through. Also a good data point for triagers: always insist on getting the net-internals log and not a reporter-provided snippet. My initial categorization (cache lock showed up again) was unrelated and was just a symptom of the root problem.

https://crbug.com/489919 - about:net-export is broken. I had a couple reporters who were unable to get me net-internals logs because the instructions didn't work. Seems to be specific to the Gmail app. We probably should also make the instructions on https://dev.chromium.org/for-testers/providing-network-details specifically have a section + screenshots for mobile.

A couple notable duplicates: we have another data point of Wajam malware crash. Also Apple's Security.framework double-close bug is still plaguing us.

For crashes, filed a bug for https://crbug.com/489393, though it doesn't seem to show up terribly often.

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

[Matt Menke]

Triage report for 2015-05-20 and 2015-05-21:

Nothing too exciting.  Did not do a great job of following up on bugs due to spending time on other stuff (codereviews, mostly)

Triaged up to 490852.

Notable new bugs:

* http://crbug.com/490734 - New crasher on Windows dev when disconnecting sockets, looks to be due to PrxDrvPE.dll.  Appears to belong to "Proxifier", which forces apps to use a proxy.  Unclear why we're not seeing it on stable.  Regardless, doesn't seem to be a bug in our code.

* http://crbug.com/489973 - We now map all *.localhost domains to 127.0.0.1, bypassing GetAddrInfo.  Had a couple people run into this and file bugs.

* http://crbug.com/490705 - User getting ERR_EMPTY_RESPONSE from www.reddit.com.  Logs show DNS resolving Reddit to an IP a reverse DNS lookup maps to his ISP.  Broken "transparent" proxy?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAF8qwaA-5%2Bqy0-s27byzMgmrkCMMh3coXO3hmQCaFA-23BLGmA%40mail.gmail.com.

[Matt Menke]

Oh, and one other thing of note - no AssertNoUrlRequest crashes on dev for the last 2 days or so.  If a future triager sees any, please file a new bug for them.

[David Benjamin]

On Thu, May 21, 2015 at 5:47 PM Matt Menke <mme...@chromium.org> wrote:

Oh, and one other thing of note - no AssertNoUrlRequest crashes on dev for the last 2 days or so.  If a future triager sees any, please file a new bug for them.

 
Yay!

[Randy Smith]

On Thu, May 21, 2015 at 5:49 PM, David Benjamin <davi...@chromium.org> wrote:
> On Thu, May 21, 2015 at 5:47 PM Matt Menke <mme...@chromium.org> wrote:
>>
>> Oh, and one other thing of note - no AssertNoUrlRequest crashes on dev for
>> the last 2 days or so. If a future triager sees any, please file a new bug
>> for them.
>
>
> Yay!

Seconded!

-- Randy

> https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAF8qwaAabbYyQen38ciHXwyMfpTRrfv0H6hSw%3DCo9w6VYE%2BsiA%40mail.gmail.com.

[Asanka Herath]

Triaged up to 491967. I still need to catch up on alerts, but so far no patterns.

Notable bugs:

491855: Data compression proxy breaks HEAD requests.

490877: SSL_PROTOCOL_ERROR in M43 (tossed at davidben@)

From staring at TLS issues and scratching my head wondering if the behavior is expected or not, I get the anecdotal impression that familiarity with TLS is going to be increasingly important for bug triage.

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

[Eric Roman]

Triaged up to 493372.

No particularly interesting bugs.

A couple around caching, but mostly user confusing on how HTTP caching works.

http://crbug.com/492771 (ERR_CONNECTION_CLOSED)

http://crbug.com/493248 (page allegedly cached when it shouldn’t be)

http://crbug.com/491533 (pdf loading stalled)

http://crbug.com/493348 (RST_STREAM/PROTOCOL_ERROR for HTTP/2 requests with > 16kb headers)

http://crbug.com/492665 (request not being cached when prefetched in page)

http://crbug.com/492519 (OOM crash when Websocket keeps delivering data)

http://crbug.com/492714 (Probably an app compat issue. Vague “page doesn’t load” bug)

http://crbug.com/492761 (WorkingAsIntended - no referrer in http pages from https)

http://crbug.com/232406 (WoringAsIntended - old bug on cache and reloading command-shift-r)

http://crbug.com/468037 (More discussion on surfacing platform network diagnostic tool)

http://crbug.com/492081 (WorkingAsIntended - User wants the flag allow-insecure-websocket-from-https-origin back, which was removed)

[Matt Mueller]

Triaged up to 494506.

Oddly quiet, few networking bugs at all.

http://crbug.com/493575 (hang with client auth on Win with smartcard in M43+)

http://crbug.com/493886 ("waiting for available socket".  Trying to get a netlog.)

http://crbug.com/493823 (DCHECK for someone using CEF. Do we care?)

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

[Misha Efimov]

Triaged up to 495750.

Entered a bunch of crashers, some of them apparently due to malware. Updated internal wiki with sleevi's and davidben's suggestions on identifying those.

Notable bug:

http://crbug.com/494817 - SDCH decoding failed on google.com search page due to adware on the machine doing SSL MITM and removing Content-Encoding header.

Few gasper alerts were just noise.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMFW8HFLkC%3DBCrAau-GvTOfpHUBX0zQwa4oX%3Dr%3D%2BYZWnG_Lrsg%40mail.gmail.com.

[Chris Bentzel]

On Wed, Jun 3, 2015 at 11:29 AM Misha Efimov <m...@chromium.org> wrote:

Triaged up to 495750.

Entered a bunch of crashers, some of them apparently due to malware. Updated internal wiki with sleevi's and davidben's suggestions on identifying those.

Notable bug:

http://crbug.com/494817 - SDCH decoding failed on google.com search page due to adware on the machine doing SSL MITM and removing Content-Encoding header.

Ugh on so many fronts. 

[Randy Smith]

On Wed, Jun 3, 2015 at 11:29 AM, Misha Efimov <m...@chromium.org> wrote:
> Triaged up to 495750.
>
> Entered a bunch of crashers, some of them apparently due to malware. Updated
> internal wiki with sleevi's and davidben's suggestions on identifying those.

Just confirming that you mean net/docs/*.md?

-- Randy

[Misha Efimov]

I mean ChromeNetworkStack wiki page that you've created a year ago. 

I'll be glad to updated net/docs/bug-triage-suggested-workflow.md if it is ok to describe internal tool. 

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

[Randy Smith]

On Wed, Jun 3, 2015 at 11:49 AM, Misha Efimov <m...@chromium.org> wrote:
> I mean ChromeNetworkStack wiki page that you've created a year ago.
>
> I'll be glad to updated net/docs/bug-triage-suggested-workflow.md if it is
> ok to describe internal tool.

I think the consensus is that it's best to keep things all in one
place even if it's describing an internal tool. I did some engagement
with people as to what's ok and what's not ok to express in an
external forum as part of doing
https://codereview.chromium.org/970953002 (which says quite a bit
about the chromecrash). I don't see anything in what you've said
that's problematic. (The main concern was not putting PII or
proprietary symbol info in the external bug tracker, which isn't
relevant to where the instructions are.)

I should look into moving the gasper notes I put on that page out;
I'll take an AI to do that.

-- Randy

[Eric Roman]

Also of interest for malware comparisons is https://goto.google.com/plqbz

[Bence Béky]

Triaged up to https://crbug.com/501991. Filed bugs for quite a few
crashes. Did bisecting to find culprits for two bugs. No gasper
alerts. Nothing extraordinary to report.

[Helen Li]

On duty 06/23 and 06/24. Triaged to 504088. No new gasper alerts. Filed bug for two crashes.

New network related bugs:

Issue 502980:Network requests don't Vary on Client-Hints Width

Issue 503488 in chromium: ServiceWorker doesn't handle trusted self-signed certificates

Issue 504024:Chrome Repeatedly Prompts for Windows Authentication

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

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

[Randy Smith]

On duty 6/29&6/30. Triaged to issue 505901.

This was a light triage duty; I spent most of it evaluating
net-internals dumps on Cr-Internals-Network bugs that hadn't gotten
any attention in a while and trying to figure out why they hadn't
gotten any attention in a while. All of crash scanning, bug scanning,
and gasper alerts were pretty simple; crash scanning because very few
releases have come out recently, and the net crashes in them had
already been registered as issues, but scanning because not many bugs
had been filed and Raman triaged well well past noon PT on his last
day, and gasper alerts because very few alerts fired.

Nothing very interesting in the bugs I looked at; the most interesting
was http://crbug.com/501795#c14, which David helped me trace down to a
very delayed response from the OS to certificate validation. Other
potential bits of interest:

* http://crbug.com/505707: Chrome ignores "Accept Ranges". Ricardo
thinks this is due to a problem with the media player.

* http://crbug.com/115916: Old bug about Chrome not being able to
access the internet after suspend/resume; the two net-internals dumps
I looked at were about hanging in system interfaces.

-- Randy

> https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEkFr0402xB5T3Sq%3DsK_TrsbV4dHqXot7xuEb%3DYS8_QeyoTKMg%40mail.gmail.com.

[Ryan Sleevi]

On Tue, Jun 30, 2015 at 3:38 PM, Randy Smith <rds...@chromium.org> wrote:

Nothing very interesting in the bugs I looked at; the most interesting
was http://crbug.com/501795#c14, which David helped me trace down to a
very delayed response from the OS to certificate validation.  Other
potential bits of interest:

Sorry that took you a while - was already digging in with the user on https://code.google.com/p/chromium/issues/detail?id=50949#c22 :/ 

[Randy Smith]

No loss on my side--I feel like I'm getting noticeably better at
parsing net-internals dumps. I keep trying to come up with some way
to speed the process up--I suspect I'm a *lot* slower on the uptake
for net-internals dumps than, say, Matt--but I'm glad to have
opportunities to learn.

-- Randy

[Siddharth Vijayakrishnan]

Triaged up to 506848, didn't see anything interesting. Didn't see any activity on gasper alerts other than a simple cache related one on android-dev which I don't think is important. Since I am on vacation, didn't spent time on investigating old reports. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAFbEG_oSGs-HSnUxXY-RTQe21pGD%3Dk%2Bvpj4v23tKZduPJovZMA%40mail.gmail.com.

[Ryan Sleevi]

Triaged up through 507190.

On the networking side, nothing terribly interesting.

https://code.google.com/p/chromium/issues/detail?id=507184 - Requests timing out after 30 seconds (initial looks to be a server issues, going to keep poking it)

https://code.google.com/p/chromium/issues/detail?id=505268 - The experimental 'HTTPS: 1' header for Upgrade Insecure Requests ( https://w3c.github.io/webappsec/specs/upgrade/#preference ) looks to be breaking some Wordpress blogs ( https://github.com/woothemes/woocommerce/issues/8479 for sample snippet of 'broken' code ). New headers are hard :(

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

[Misha Efimov]

Triaged up to 508528, nothing particularly exciting.

Learned that gasper alerts correlated with significant change of volume should be ignored.

Investigated a couple of issues, for example http://crbug.com/502226 which had symptoms of network related, but turned out to be caused by javascript engine changes.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvajO%2BVH8wVVc2wfG9RhBHQpLZx%2B-z11_%3D_YiwERnp21CA%40mail.gmail.com.

[Bryan McQuade]

Triaged up to 509066

Identified 2 new crashers that could use additional investigations;
crbug.com/509066: Crash in net::TCPSocketWin::Write

crbug.com/509046:  Crash in net::CertVerifyProcWin::VerifyInternal

both of these signatures were typically associated with malware but it appears there is also a real net stack bug for each, unrelated to malware.

Notable other issues:

crbug.com/508231:  27.0% regression in Net.HttpTimeToFirstByte-android-dev on 2015-06-23 - probably nothing, but worth watching for a few more days

crbug.com/289715:  Chrome_Mac: Crash Report - Magic Signature: net::URLRequestHttpJob::SaveCookiesAndNotif... - recently unassigned by battre@. Should try to find a new owner.

crbug.com/504416: Chrome: Crash Report - net::URLRequestJob::RecordBytesRead - I think this had been misassigned to tbansal, so just unassigned.

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

[Siddharth Vijayakrishnan]

On 13 July 2015 at 08:55, Bryan McQuade <bmcq...@chromium.org> wrote:

Triaged up to 509066

Identified 2 new crashers that could use additional investigations;
crbug.com/509066: Crash in net::TCPSocketWin::Write

crbug.com/509046:  Crash in net::CertVerifyProcWin::VerifyInternal

both of these signatures were typically associated with malware but it appears there is also a real net stack bug for each, unrelated to malware.

Notable other issues:

crbug.com/508231:  27.0% regression in Net.HttpTimeToFirstByte-android-dev on 2015-06-23 - probably nothing, but worth watching for a few more days

crbug.com/289715:  Chrome_Mac: Crash Report - Magic Signature: net::URLRequestHttpJob::SaveCookiesAndNotif... - recently unassigned by battre@. Should try to find a new owner.

​What's the priority on this ? It says P1, which to me means that we should try and fix this by the next release milestone which is M46 currently. 

​

 

crbug.com/504416: Chrome: Crash Report - net::URLRequestJob::RecordBytesRead - I think this had been misassigned to tbansal, so just unassigned.

​Looks like Paul has started looking at this. ​