Clear json object
nlohmann::json::clear() has different behavior dependent on what the
underlying object is, rather than doing the expected behavior of
completely clearing the json object. This didn't matter because of a
similar bug in http_connection that relied on nlohmann:json::empty()
which is ALSO type dependent, so these worked.
Unfortunately, in 02e01b5108d46720a0b438c0d79952464320d954 we wanted to
allow empty objects, and this bug was exposed.
There are two places where clear() is used, once in Response, which is
clearly not the intent, which is to reset the object to the original
constructed state. The other place we call clear is in Manager, where
we use it to clear incremental results. That was a previous best practice that has been eliminated everywhere else (now we return as
many results with the error as we are able). It has been removed.
Tested: Logging into the webui in firefox no longer core dumps.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Ic89a037b30fb40c0e6eaeb939cae6e006dd0ffac
diff --git a/http/http_response.hpp b/http/http_response.hpp
index 58e047c..bece17a 100644
--- a/http/http_response.hpp
+++ b/http/http_response.hpp
@@ -176,7 +176,7 @@
{
BMCWEB_LOG_DEBUG << this << " Clearing response containers";
stringResponse.emplace(response_type{});
- jsonValue.clear();
+ jsonValue = nullptr;
completed = false;
expectedHash = std::nullopt;
}
@@ -272,7 +272,7 @@
addHeader(boost::beast::http::field::etag, hexVal);
if (expectedHash && hexVal == *expectedHash)
{
- jsonValue.clear();
+ jsonValue = nullptr;
result(boost::beast::http::status::not_modified);
}
}
diff --git a/redfish-core/lib/managers.hpp b/redfish-core/lib/managers.hpp
index eb453f2..5904f5d 100644
--- a/redfish-core/lib/managers.hpp
+++ b/redfish-core/lib/managers.hpp
@@ -295,7 +295,6 @@
if (ec)
{
BMCWEB_LOG_ERROR << ec;
- asyncResp->res.jsonValue.clear();
messages::internalError(asyncResp->res);
return;
}