1366174 - Network freeze

Status: RESOLVED DUPLICATE of bug 1360574

(Core :: Networking: HTTP, defect)

Description

[Dragana Damjanovic [:dragana]]

In bug 1364370 the reporter notice a network freezing.

I am opening a new bug to separate issues.

So bug 1364370 comment 3 describes this issue.

I asked for a log and the log is:
https://ftp.office.modum.by/pub/ffnetlog.7z

Comment 1

[Daniel Stenberg [:bagder]]

This seems to require Pipelining to be enabled, right? If so, I think disabling it is a decent work-around since it has been removed completely in later versions.

Comment 2

[Dragana Damjanovic [:dragana]]

I have look at the log yesterday, but I have not seen what is wrong. I will need some more help.

The pipelining is disabled (I do not see any pipeling in the log).

Can you explain me what is happening:
Is the firefox user interface freezing? You can use it and it is responding?
"Network freezing" means the pages are not loading promptly, but they are taking to long?
Do you know which page was loading when your notice this?

The log is large, i see socketThread running normally. At some point it is sleeping for a log time, but that is normal if nothing is happening on the network, e.g. no network request is active.

Comment 3

[Dragana Damjanovic [:dragana]]

(In reply to Daniel Stenberg [:bagder] from comment #1)
> This seems to require Pipelining to be enabled, right? If so, I think
> disabling it is a decent work-around since it has been removed completely in
> later versions.

I think pipelining is disabled. I do not see it in the log.

Comment 4

[Daniel Stenberg [:bagder]]

(In reply to Dragana Damjanovic [:dragana] from comment #3)

> I think pipelining is disabled. I do not see it in the log.

I didn't actually check the corresponding code yet, I just say this style of mentions in the log saying "pipeline cancellation" (plus the talk about pipelining in the parent bug):

2017-05-17 07:05:34.147000 UTC - [Socket Thread]: V/nsHttp Read delta ms of 6391 causing slow read major event and pipeline cancellation

Comment 5

[Dragana Damjanovic [:dragana]]

I looked for "Pipel" in the code. I think when we use pipelingin there is nsHttpPipeline in a log.

017-05-17 07:05:11.732000 UTC - [Socket Thread]: V/nsHttp Read delta ms of 25029 causing slow read major event and pipeline cancellation

I think we can have that log without pipeline as well. 

I think the log message means that the respons from server took too long.

Comment 6

[Maxim Britov]

Hello
This session with removed pipeline options in config.

Firefox UI work as usual. User can shwitch tabs, read, scroll, update... but update never finished.
I can open new tab, enter for example modum.by or local ip 192.168.x.x and nothing... just usual indication on tab header.
Users behind squid proxy, but local ip doesn't work too.

I have two test users with FF 52esr, all other still on FF 45esr.
I think issue come with 52.1.0-build1. May be...

One of users said: Ff freeze when he forgot about opened app and open new url in new window. When he work with one window freezes never happens (may be...).
Second user can reproduce freezed on regular basis. She always uses FF in 3 windows. LOG from this user.

I found 52.1.0-build2 have portion net netwerk/ code.
I also see new 52.1.2 with new netwerk/ code again.
My test user on vacation from today till monday. In monday she will check 52.1.2 on her 3 windowed FF :)

Thanks

Comment 7

[Maxim Britov]

I dropped log file on my server. Please ask it it need again.

Comment 8

[Maxim Britov]

May be duplicate of bug 1360574
"Firefox stops working after 900 connections when using NTLM proxy"

Comment 9

[Dragana Damjanovic [:dragana]]

(In reply to Maxim Britov from comment #8)
> May be duplicate of bug 1360574
> "Firefox stops working after 900 connections when using NTLM proxy"

It is:

2017-05-17 08:09:13.755000 UTC - [Socket Thread]: V/nsHttp   num active conns == max conns