You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 76a300f
Browse filesBrowse the repository at this point in the historyBrowse files
fix(test): stop the test server lying about listening, aborting, and wedging
Three bugs in the v1 integration test server, all found while chasing the
Two-VM GPU Direct lane, all of which cost time by describing themselves as
something else.
runThreaded() called FD_SET(listen_fd_, &fds) with no guard. runOnce() has
always checked listen_fd_ < 0; the threaded loop did not, and FD_SET(-1) is
a glibc fortify abort. So a port already in use did not report a busy port
-- it killed the process with "bit out of range 0 - FD_SETSIZE on fd_set",
which names no port and suggests memory corruption. Under systemd that
arrived as code=dumped, status=6/ABRT. startThreaded() now refuses to spawn
the thread without a socket, and the loop holds the invariant itself since
it is reachable directly.
main() never checked that start returned. It printed "listening on port N"
unconditionally -- the line every caller waits for before it starts sending
-- so a server that had already failed to bind announced itself ready and
then died. startThreaded() returns bool; both call sites check it and exit 1
with the port in the message. The constructor also says why the bind failed,
where it failed, rather than leaving a half-built object to abort later.
The RC QP was only reset on the success paths. One QP serves every request
in turn, and an RC QP already in RTS cannot be moved to RTR for the next
client, so a single failed transfer wedged the server for everyone after it:
each subsequent request returned "could not connect the RC QP to the
client", naming the wrong fault and burying the real one. Not hypothetical
-- it invalidated a size sweep on the lab, where four sizes appeared to fail
on their merits and had in fact never reached the wire. Reset moves into
Impl::resetQp(), runs on every path that touched the QP, and clears `ready`
if the rebuild itself fails rather than serving a QP it no longer has.
Verified on the two-guest lab: a transfer that fails is followed by two that
succeed against the same server instance, with one failure line in the log
and none after it. Two servers on one port give
hipobj-rdma-test-server: cannot bind port 9321: Address already in use
hipobj-rdma-test-server: not listening on port 9321
and exit 1, where the second used to abort. ctest is 12/12.
The QP reset is confirmed working in CI: the Two-VM GPU Direct client now
retries and gets the same error both times, where before the retry reported
a connect failure and hid the original fault.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Stephen Bates <sbates@raithlin.com>
0 commit comments