1868070 - Intermittently the socket thread uses 100% of a single logical core and the browser drops all connections

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[tgn-ff]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:122.0) Gecko/20100101 Firefox/122.0

Steps to reproduce:

This is an intermittent issue, I don't have STR. This might be triggered by youtube. (I'm never logged in and I use uBO).

Actual results:

Suddenly, the browser starts using a lot of CPU. about:processes show most of the CPU to be used by the socket thread. When that happens all connections are dropped. Exiting Firefox doesn't terminate its processes.

Expected results:

The first time I experienced this issue was in BuildID 20231201095335.

Attempting to capture an HTTP log results in an empty log.

Attempting to capture a performance profile with the Firefox profiler is impossible without an internet connection, since saving the profile locally requires to open it in the profile site first... Should I report this somewhere?

This is a profile I captured with perf: https://share.firefox.dev/46Gd42T

This is the resulting crash report when killing the main process which hangs on exit: https://crash-stats.mozilla.org/report/index/752f9a78-caed-46e0-b719-7cd890231202 https://crash-stats.mozilla.org/report/index/0525b25a-2682-41f5-a3e9-c4e460231204

Comment 1

[tgn-ff]

It happened again. This time when doing a Google search through the urlbar (suggestions disabled).

Just to be clear, this is not a performance issue, Firefox is unusable whenever that happens and requires a restart, otherwise it cannot load any site.

https://crash-stats.mozilla.org/report/index/fc029fce-439f-41ad-ac4f-dfda00231206

Comment 2

[Kershaw Chang [:kershaw]]

Hi Reporter,

Could you set this pref network.http.http3.max_accumlated_time_ms to 0 and see if this happens again?

Thanks.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a crash signature, thus the bug will be considered confirmed.

Comment 4

[Kershaw Chang [:kershaw]]

The crash signature is not related to this bug.

Comment 5

[Kershaw Chang [:kershaw]]

Attachment: Bug 1868070 - Make sure we exit the loop when neqo returns a zero duration, r=#necko

Comment 6

[Kershaw Chang [:kershaw]]

I think the problem here is that neqo returns a zero duration from this line. When this happens, the accumulated_time is never accumulated, so we stuck in this loop forever.

Comment 7

[Donal Meehan [:dmeehan]]

Tracking this for Fx122 as it was triaged as an S2.
:kershaw is this a regression introduced by Bug 1852924?

Comment 8

[Kershaw Chang [:kershaw]]

(In reply to Donal Meehan [:dmeehan] from comment #7)

Tracking this for Fx122 as it was triaged as an S2.
:kershaw is this a regression introduced by Bug 1852924?

Yes, this is introduced by Bug 1852924.

Comment 9

[tgn-ff]

(In reply to Kershaw Chang [:kershaw] from comment #2)

Could you set this pref network.http.http3.max_accumlated_time_ms to 0 and see if this happens again?

I've set the pref yesterday and so far I haven't encountered it yet. However, sometimes this occurred three or more times in a day and other days it didn't occur at all, so I'm not sure it did anything yet. I'll report in a week unless it happens again sooner than that.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7fc200daf13a
Make sure we exit the loop when neqo returns a zero duration, r=necko-reviewers,valentin

Comment 11

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/7fc200daf13a

Comment 12

[tgn-ff]

I haven't encountered the bug since. I reset the pref as soon as the patch landed. It seems it's fixed.

Comment 13

[Kershaw Chang [:kershaw]]

(In reply to tgn-ff from comment #12)

I haven't encountered the bug since. I reset the pref as soon as the patch landed. It seems it's fixed.

Thanks for verifying.