684758 - pt_ConnectContinue should also check for PR_POLL_HUP

Status: RESOLVED FIXED

(NSPR :: NSPR, defect, P1)

Description

[flo]

Attachment: patch to fix the issue

On FreeBSD when you try to connect to a Host/Port where nothing listens, i.e. the webserver is down, firefox goes into a loop and uses 100% CPU. This can easily be reproduced by connecting to http://localhost:randomport, where randomport is a port where no service is listening.

Andriy Gapon tracked this down to pt_ConnectContinue in ptio.c of nspr. It should also check for PR_POLL_HUP. A patch is attached. With the attached patch we are not able to reproduce the problem anymore.

Comment 1

[Wan-Teh Chang]

Attachment: patch to fix the issue (v2) by Florian Smeets

Thanks for the patch.  NSPR expects poll() to report
POLLOUT in this case, indicating the socket is writable.
(The expected behavior is that a socket becomes both
readable and writable if the connect failed.)  I guess
FreeBSD uses POLLHUP only to report that the socket is
writable when the connect failed in this way.

Patch checked in on the NSPR trunk (NSPR 4.9).

Checking in ptio.c;
/cvsroot/mozilla/nsprpub/pr/src/pthreads/ptio.c,v  <--  ptio.c
new revision: 3.117; previous revision: 3.116
done

Comment 2

[(no longer active)]

Pushed to mozilla-central in the latest NSPR update: https://hg.mozilla.org/mozilla-central/rev/7e25caedd620