1497868 - Parent process hangs when playing a media from FTP server

Status: RESOLVED FIXED

(Core Graveyard :: Networking: FTP, defect, P2)

Description

[emuser20140816]

Steps to reproduce:
1. Put a media file (mp3, mp4 etc) on your FTP server
2. Access via Firefox browser
3. Spam reload (or back or close browser before the media is fully downloaded)

What happened?:
Parent process starts to eat CPU usage. When browser is exited, it will leave as zombie process.

Reproduced on:
Firefox Nightly 64.0a1 x64 (2018-10-09)
Firefox 62.0.3 x86

Comment 1

[Junior [inactive]]

Hello Reporter,
Thanks for filing this bug.
Given it's reproducible on nightly and release, it's not a near regression.
I'm wondering that can you reproduce it in a HTTP server instead of FTP?
It helps to locate where the problem is.

Thanks!

Comment 2

[emuser20140816]

I've tried it on HTTP server in the same way but the problem wasn't reproducible.
This could only happen in FTP media playback. In particular when tab page is moved/reloaded while the media is partially loaded.

Comment 3

[emuser20140816]

Attachment: A video of procedure

A video of procedure is attached.

Comment 4

[Dragana Damjanovic [:dragana]]

Can you please make a log: 
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
 please add nsFtp:5 to the list:
imestamp,rotate:200,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5 

thanks.

Comment 5

[emuser20140816]

Attachment: FTP networking log

(In reply to Dragana Damjanovic [:dragana] from comment #4)
> Can you please make a log: 
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
>  please add nsFtp:5 to the list:
> imestamp,rotate:200,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5 
> 
> thanks.

Log file is in attachment.

Comment 6

[Dragana Damjanovic [:dragana]]

We used a buffered input for ftp. A pipe is created at:
https://searchfox.org/mozilla-central/source/netwerk/protocol/ftp/nsFtpConnectionThread.cpp#1571

We never cancel it (https://searchfox.org/mozilla-central/source/netwerk/protocol/ftp/nsFtpConnectionThread.cpp#2129), but that is ok because trying to read from the socket will return an error and the pipe will be closed. The problem appears when the pipe buffer is full: we check whether there is some place in the buffer(the pipe's buffer) and because there is no space we never access the socket and never pickup that the socket is closed.

I am not an expert in Pipes and AsyncCopiers.
Canceling pipe at nsFtpState::CloseWithStatus(nsresult status) works. Is it right approach. Would be possible that we have a similar problem elsewhere?

Comment 7

[Honza Bambas (:mayhemer)]

(In reply to Dragana Damjanovic [:dragana] from comment #6)
> We used a buffered input for ftp. A pipe is created at:
> https://searchfox.org/mozilla-central/source/netwerk/protocol/ftp/
> nsFtpConnectionThread.cpp#1571
> 
> We never cancel it
> (https://searchfox.org/mozilla-central/source/netwerk/protocol/ftp/
> nsFtpConnectionThread.cpp#2129), but that is ok because trying to read from
> the socket will return an error and the pipe will be closed. The problem
> appears when the pipe buffer is full: we check whether there is some place
> in the buffer(the pipe's buffer) and because there is no space we never
> access the socket and never pickup that the socket is closed.

OK, so at [1] we open the socket transport.  At [2] we open the input stream as buffered to read data from the socket and keep it in mDataStream, we keep input stream of the pipe and there is a stream copier between the socket and the pipe.  When the pipe is full, the stream copier will take care to wait for the pipe's output to free up and then poll the socket again for reading and restart feeding.  If stop reading from the pipe, it will hang, yes.

> 
> I am not an expert in Pipes and AsyncCopiers.
> Canceling pipe at nsFtpState::CloseWithStatus(nsresult status) works. Is it
> right approach. Would be possible that we have a similar problem elsewhere?

Closing the input is the right way (status or NS_BASE_STREAM_CLOSED will likely do the job).


[1] https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/netwerk/protocol/ftp/nsFtpConnectionThread.cpp#1507-1512
[2] https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/netwerk/protocol/ftp/nsFtpConnectionThread.cpp#1571-1576

Comment 8

[Dragana Damjanovic [:dragana]]

Attachment: In nsFtp, close data pipe as well.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1de661bbcc0c
In nsFtp, close data pipe as well. r=mayhemer

Comment 10

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/1de661bbcc0c

Comment 11

[Ciprian Georgiu, Desktop QA]

I've tried to reproduce this issue, but it seems that it is quite intermittent on my machine; I was only able to see some firefox.exe processes left opened after closing the browser, but I cannot reproduce this constantly on Windows 7 x64. The CPU usage in my case have only spiked at about ~20%, even though I've tried to spam the refresh button for a couple of times. FileZilla was used, FWIW, for creating the FTP server.

Hi emuser20140816,

Since I was able to reproduce this bug only partially, and not regularly on my machine, could you please help us verify this bug and tell us if this build fix the issue on your end as well? Thank you!

Comment 12

[Tania Maity (:tmaity)]

Since there was no information received on the above question, after checking with Ryan VanderMeulen [:RyanVM], I am removing the qe verify+ flag here.