sxia-aviatrix commented on code in PR #13574:
URL: https://github.com/apache/trafficserver/pull/13574#discussion_r3834135895
##########
src/proxy/http/HttpSM.cc:
##########
@@ -2145,6 +2145,17 @@ HttpSM::state_read_server_response_header(int event,
void *data)
// If there is a post body in transit, give up on it
if (tunnel.is_tunnel_alive()) {
tunnel.abort_tunnel();
+ // abort_tunnel() does not clean up vc_table entries. If a request
+ // transform is present, post_transform_info.entry still points at the
+ // TransformVConnection whose chain will be freed by the abort cascade.
+ // Clean it up now so cleanup_all() in kill_this() does not call
+ // do_io_close() on freed memory.
+ if (post_transform_info.entry != nullptr) {
+ post_transform_info.entry->in_tunnel = false;
+ vc_table.cleanup_entry(post_transform_info.entry);
+ post_transform_info.entry = nullptr;
Review Comment:
Good catch on the pairing. I traced both sites:
**`tunnel_handler_post_or_put()`** — Cannot be reached after this
`abort_tunnel()`. It fires via `HTTP_TUNNEL_EVENT_DONE`, but `abort_tunnel()`
sets `active = false`, marks all producers/consumers dead, and calls `reset()`.
The tunnel will never deliver that callback again.
**`handle_server_setup_error()`** — Safe as you noted: `abort_tunnel()`
calls `reset()`, so `tunnel.get_consumer(post_transform_info.vc)` returns
`nullptr` and the inner guard short-circuits before touching `.entry`.
The `entry == nullptr && vc != nullptr` state also matches the existing
pattern at line 2929 (`tunnel_handler_post_or_put` itself does this) and in
`state_common_wait_for_transform_read()`'s `TRANSFORM_FAIL` case.
So I'll keep `.vc` non-null to stay consistent with the rest of the file.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
