Open
Bug 1251212
Opened 8 years ago
Updated 2 years ago
proxy_tunnel_socket_unittest is broken
Categories
(Core :: WebRTC: Networking, defect, P3)
Core
WebRTC: Networking
Tracking
()
People
(Reporter: bwc, Unassigned)
Details
Attachments
(1 file)
5.96 KB,
text/plain
|
Details |
Several test-cases in proxy_tunnel_socket_unittest are broken.
Comment 1•8 years ago
|
||
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•8 years ago
|
||
I'm a bit confused. There's probably a reason the tests were disabled....
Reporter | ||
Updated•8 years ago
|
backlog: --- → tech-debt
Rank: 25
Flags: needinfo?(docfaraday)
Priority: -- → P2
Comment 4•8 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
Comment 5•7 years ago
|
||
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Comment 6•6 years ago
|
||
I don't have the capacity any more to work on this any time soon.
Assignee: drno → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•