Repository navigation
Need DestructorGuard in HQSession::handleWriteError(HQStreamTransportBase* hqStream, quic::QuicErrorCode err)? #582
Description
Hi, our codebase uses proxygen and recently we saw a crash inside the proxygen HTTPTransaction/HQSession stack. It looks like the underlying txn object was gone inside the dguards destructor.
Could it be that there should be a DestructorGuard in the method HQSession::handleWriteError as well? The comment also seems to suggest similar concern.
https://github.com/facebook/proxygen/blob/f9652e5b307a5c9eec245a5ab1ca97494823b165/proxygen/lib/http/session/HQSession.cpp#L1967-L1973
While this crash is not easily reproducible as this is our first time seeing it, I wonder what the thoughts are from the team. Thanks.
Core dump after crash:
* thread #1, name = '', stop reason = signal SIGSEGV: address not mapped to object
* frame #0: 0x0000000001831c13 `folly::DelayedDestructionBase::DestructorGuard::~DestructorGuard(this=<unavailable>) at DelayedDestructionBase.h:94:16
frame #1: 0x00000000019026e8 `proxygen::HTTPTransaction::processIngressError(this=<unavailable>, error=<unavailable>) at HTTPTransaction.cpp:762:1
frame #2: 0x000000000194a451 `proxygen::HQSession::handleWriteError(proxygen::HQSession::HQStreamTransportBase*, quic::QuicErrorCode) [inlined] proxygen::HQSession::HQStreamTransportBase::errorOnTransaction(this=0x000000013d286628, ex=HTTPException @ 0x00007f54a7be1888) at HQSession.cpp:985:10
frame #3: 0x000000000194a42d `proxygen::HQSession::handleWriteError(this=<unavailable>, hqStream=<unavailable>, err=<unavailable>) at HQSession.cpp:1974:13
frame #4: 0x000000000193a5e5 `proxygen::HQSession::onStopSending(this=<unavailable>, id=<unavailable>, error=<unavailable>) at HQSession.cpp:268:5
frame #5: 0x0000000001a63fc1 `quic::QuicTransportBaseLite::handleStreamStopSendingCallbacks(this=<unavailable>) at QuicTransportBaseLite.cpp:1957:20
frame #6: 0x0000000001a62301 `quic::QuicTransportBaseLite::processCallbacksAfterNetworkData(this=<unavailable>) at QuicTransportBaseLite.cpp:1571:3
frame #7: 0x0000000001a5fc60 `quic::QuicTransportBaseLite::onNetworkData(this=<unavailable>, peer=<unavailable>, networkData=<unavailable>) at QuicTransportBaseLite.cpp:145:7
frame #8: 0x00000000019ceea7 `quic::QuicServerWorker::dispatchPacketData(folly::SocketAddress const&, quic::RoutingData&&, quic::NetworkData&&, folly::Optional<quic::QuicVersion>, bool)::$_1::operator()(this=<unavailable>, transport=<unavailable>) const at QuicServerWorker.cpp:855:16
frame #9: 0x00000000019cd886 `quic::QuicServerWorker::dispatchPacketData(this=<unavailable>, client=<unavailable>, routingData=<unavailable>, networkData=<unavailable>, quicVersion=<unavailable>, isForwardedData=false) at QuicServerWorker.cpp:0
Activity
afrind commentedon Nov 1, 2025
I am the author of that comment (in 2018 lol). I'm not sure adding another dguard there will help with the stack you have though, I think it would just delay observing the the crash until the new dguard is destroyed in handleWriteError.
What does your application do when it receives onError?
ryanchiu0416 commentedon Nov 1, 2025
Thanks for the quick response. In the app handler's
::onError(const proxygen::HTTPException& error), it callstxn_->sendAbort();The last app log is the following, before it crashed:
afrind commentedon Nov 1, 2025
If you have a core file, any memory state of the transaction or session might be helpful. The HTTPTransaction is supposed to be protected against premature destruction by the guard in processIngressError, but it seems to die exiting that routine.