Open Bug 1251212 Opened 8 years ago Updated 2 years ago

proxy_tunnel_socket_unittest is broken

Categories

(Core :: WebRTC: Networking, defect, P3)

defect

Tracking

()

Tracking Status
firefox47 --- affected
backlog tech-debt

People

(Reporter: bwc, Unassigned)

Details

Attachments

(1 file)

Several test-cases in proxy_tunnel_socket_unittest are broken.
Attached file Test failure log
Test failure details from running:

> GTEST_ALSO_RUN_DISABLED_TESTS=1 ./mach gtest ProxyTunnelSocketTest.*

The final crash is due to an assert in |mozilla::DummySocket::getaddr| [1] which is unimplemented.

[1] https://dxr.mozilla.org/mozilla-central/rev/d848a5628d801a460a7244cbcdea22d328d8b310/media/mtransport/test/dummysocket.h#79
I'm a bit confused. There's probably a reason the tests were disabled....
byron - what priority should this be?
Flags: needinfo?(docfaraday)
backlog: --- → tech-debt
Rank: 25
Flags: needinfo?(docfaraday)
Priority: -- → P2
I'm pretty sure I know what is going on here: I recently changed the behavior for proxy tunnel sockets to return R_WOULDBLOCK as long as we haven't received a success response for the HTTP Connect request. Apparently when I landed that change I overlooked these tests here, as they aren't/weren't executed in treeherder (why?).
These tests seems to assume that the socket is writable right after calling connect, which I find a strange assumption. Especially as connecting to the proxy includes multiple delaying steps: DNS resolution, TCP connection establishing and waiting for HTTP response.
Assignee: nobody → drno
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
I don't have the capacity any more to work on this any time soon.
Assignee: drno → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: