serialCorePost segfaults on a failed request instead of failing gracefully
We hit a 100% reproducible Houdini crash whenever resolvePath() ends up going through the POST-based resolve flow and the request to the AYON server fails for any reason. Every crash lands in the same spot:
AyonApi::serialCorePost(...)
AyonApi::SPOST(...)
AyonApi::resolvePath(...)
ResolverContextCache::getAsset(...)
Signal 11, same offset every time. Poked at it with gdb and the fault is a null pointer read at what looks like response->status:
mov 0x20(%rdx),%eax <- rdx is 0x0 here
Looking at the code, serialCorePost does this:
response = m_ayonServer->Post(endPoint, headers, Payload, "application/json");
responseStatus = response->status;
cpp-httplib doesn't throw when a request fails to connect or complete, it just returns a null Result. There's a catch (const httplib::Error&) a bit further down but that never fires for this, since it's not an exception. So any failed POST dereferences a null result and takes the whole DCC down with it.
The sibling GET path (used in getSiteRoots()) already handles this correctly with a null check and a clean log message, serialCorePost just doesn't have the equivalent guard.
Repro is basically: anything that makes the underlying request fail (bad network, TLS hiccup, server restart mid-resolve, whatever) while resolving inside a DCC that cooks on its main thread (confirmed in Houdini 21, the resolve runs inline via a TBB task arena on the UI thread) and you get an instant crash instead of a clean error.
We ran into this because every request was failing due to a separate bug in the resolver itself (filed separately, an OpenSSL symbol interposition issue that made every TLS verification fail regardless of actual network/cert state), so this was very easy to reproduce, but the underlying null-deref is independent of what actually causes the request to fail. It's not a Houdini-specific bug either, serialCorePost is shared code and any DCC using it would hit the same crash under the right conditions, Houdini just made it trivially reproducible because of the other issue.
serialCorePost segfaults on a failed request instead of failing gracefully
We hit a 100% reproducible Houdini crash whenever
resolvePath()ends up going through the POST-based resolve flow and the request to the AYON server fails for any reason. Every crash lands in the same spot:Signal 11, same offset every time. Poked at it with gdb and the fault is a null pointer read at what looks like
response->status:Looking at the code,
serialCorePostdoes this:cpp-httplib doesn't throw when a request fails to connect or complete, it just returns a null
Result. There's acatch (const httplib::Error&)a bit further down but that never fires for this, since it's not an exception. So any failed POST dereferences a null result and takes the whole DCC down with it.The sibling GET path (used in
getSiteRoots()) already handles this correctly with a null check and a clean log message,serialCorePostjust doesn't have the equivalent guard.Repro is basically: anything that makes the underlying request fail (bad network, TLS hiccup, server restart mid-resolve, whatever) while resolving inside a DCC that cooks on its main thread (confirmed in Houdini 21, the resolve runs inline via a TBB task arena on the UI thread) and you get an instant crash instead of a clean error.
We ran into this because every request was failing due to a separate bug in the resolver itself (filed separately, an OpenSSL symbol interposition issue that made every TLS verification fail regardless of actual network/cert state), so this was very easy to reproduce, but the underlying null-deref is independent of what actually causes the request to fail. It's not a Houdini-specific bug either,
serialCorePostis shared code and any DCC using it would hit the same crash under the right conditions, Houdini just made it trivially reproducible because of the other issue.