proxy_tunnel_socket_unittest is broken

NEW
Assigned to

Status

()

P3
normal
Rank:
25
3 years ago
11 months ago

People

(Reporter: bwc, Assigned: drno)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox47 affected)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Several test-cases in proxy_tunnel_socket_unittest are broken.

Comment 1

3 years ago
Created attachment 8723828 [details]
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

Comment 2

3 years ago
I'm a bit confused. There's probably a reason the tests were disabled....
byron - what priority should this be?
Flags: needinfo?(docfaraday)
(Reporter)

Updated

3 years ago
backlog: --- → tech-debt
Rank: 25
Flags: needinfo?(docfaraday)
Priority: -- → P2
(Assignee)

Comment 4

3 years ago
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
You need to log in before you can comment on or make changes to this bug.