ARCHIVE/xahaud
3
0
Fork 0
mirror of https://github.com/Xahau/xahaud.git synced 2025-12-01 16:05:52 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(ValidatorSite): handle rare null pointer dereference in timeout: (#4420)

Browse Source 
In rare circumstances, both `onRequestTimeout` and the response handler
(`onSiteFetch` or `onTextFetch`) can get queued and processed. In all
observed cases, the response handler processes a network error.
`onRequestTimeout` usually runs first, but on rare occasions, the
response handler runs first, which leaves `activeResource` empty.
This commit is contained in:
Ed Hennis
2023-03-16 10:32:22 -07:00
committed by GitHub
parent 10555faa92
commit 1c9df69b33
1 changed files with 13 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
src/ripple/app/misc/impl/ValidatorSite.cpp
View File

@@ -316,8 +316,19 @@ ValidatorSite::onRequestTimeout(std::size_t siteIdx, error_code const& ec)
{ {
std::lock_guard lock_site{sites_mutex_}; std::lock_guard lock_site{sites_mutex_};
JLOG(j_.warn()) << "Request for " << sites_[siteIdx].activeResource->uri // In some circumstances, both this function and the response
<< " took too long"; // handler (onSiteFetch or onTextFetch) can get queued and
// processed. In all observed cases, the response handler
// processes a network error. Usually, this function runs first,
// but on extremely rare occasions, the response handler can run
// first, which will leave activeResource empty.
auto const& site = sites_[siteIdx];
if (site.activeResource)
JLOG(j_.warn()) << "Request for " << site.activeResource->uri
<< " took too long";
else
JLOG(j_.error()) << "Request took too long, but a response has "
"already been processed";
} }
std::lock_guard lock_state{state_mutex_}; std::lock_guard lock_state{state_mutex_};