If this error is thrown rather than a specific error returned from the async process, it means the async process is unable to write the status files for some reason and the only way to get the error is out of the async log.
This hint includes the exact async log path and name to make finding errors easier.
This doesn't solve the problem of the variant code making far too many copies, but it at least plugs the leaks.
jsonReadVarRecurse() could leak KeyValue and VariantList.
kvDup() leaked object allocations into the calling context.
kvDefault() gets a more efficient return structure.
kvGetList() leaked a Variant into the calling context.
varLstNewStrLst() leaked object allocations into the calling context. Update varLstDup() to reflect changes made in varLstNewStrLst().
Only set -DDEBUG_MEM for the modules currently being tested rather than globally.
Also run tests in a temp mem context. Running in the top context can confuse memory accounting when a new context is created in the top context.
storageS3Helper() leaked a few Strings which ended up in a long-lived context.
storageS3AuthAuto() and storageS3AuthWebId() were cleaned up by their callers but since they are not called often a temp mem context seems better.
storageS3Request() leaked an HttpRequest.
storageS3Info() leaked an HttpResponse.
storageS3PathRemoveInternal() leaked a variety of objects. Fix by freeing some of them and adding a temp mem context.
storageS3Remove() leaked an HttpResponse object.
storageWriteS3Part() leaked an HttpResponse object.
storageRemoteFilterGroup() leaked a number of objects. Use a temp mem context to prevent that.
storageRemoteProtocolInfoListCallback() leaked a PackWrite.
storageWriteRemoteFreeResource() leaked a PackWrite.
storageGcsAuthToken() memory was being cleaned up by the calling context, but seems better to keep this tidy and add a temp mem context.
storageGcsRequest() leaked an HttpRequest.
storageGcsInfo() leaked a number of objects. Use a temp mem context to prevent that.
storageGcsPathRemoveCallback() leaked an HttpResponse.
storageGcsRemove() leaked an HttpReponse.
storageWriteGcsVerify() leaked a number of objects. Use a temp mem context to prevent that.
storageWriteGcsBlock) leaked an HttpReponse.
Reuse the section/key/value Strings by truncating them instead of creating a new one every time.
Also add an error for empty sections. This function is only used for loading info files (not config files), which should never contain an empty section.
These functions allow conversion from substrings without needing to create a String or a temporary buffer.
httpDateToTime() no longer requires a temp mem context. Also improve handling of month search to avoid an allocation.
httpUriDecode() no longer requires a temp mem context.
jsonReadStr() no longer requires a temp mem context.
pgLsnFromWalSegment() no longer requires a temp mem context.
pgVersionFromStr() no longer requires a temp mem context. Also do a bit of refactoring.
storageGcsCvtTime() no longer leaks six Strings per call.
storageS3CvtTime() no longer leaks six Strings per call.
This was missed in ccc255d3 when the TLS server was introduced, probably because work on that commit preceded when the macros were introduced in 475b57c8. It would have been easy to miss in a merge.
storageAzureHelper() leaked a few Strings which ended up in a long-lived context.
storageAzureNew() failed to make a copy of the endpoint. This worked because storageAzureHelper() leaked the endpoint into the long-lived parent context.
storageAzureRequest() leaked an HttpRequest.
storageAzureInfo() leaked an HttpResponse.
storageAzurePathRemoveCallback() leaked an HttpResponse.
storageAzureRemove() leaked an HttpResponse.
pgLsnFromWalSegment() leaked two Strings.
Refactor pgLsnRangeToWalSegmentList() to create the StringList in the calling context rather than moving it later.
These leaks were not a big deal individually and there are generally few protocol objects created, but the leaks ended up in mem contexts that persist for most of execution. It makes sense to keep long-lived contexts as tidy as possible.
Refactor so that error detail is only logged in one place. This reduces calls to exitErrorDetail() and LOG_INTERNAL_FMT().
Fix minor leaks in exitErrorDetail() and exitSafe().
Move the temp mem context out of verifyJobCallback() into verifyBackup() and verifyArchive(). This makes it clearer that verifyJobCallback() allocates no memory and reduces mem usage when both verifyBackup() and verifyArchive() are called.
Update verifyErrorMsg() to return zero-terminated strings to save on allocations. The output of this function is used when formatting strings so this is also simpler. Do a similar thing in verifyRender().
Also fix a minor leak in verifyInfoFile().
Object variables were begin allocated in the calling context rather than the object context.
This is not a live bug because Exec objects are currently created and opened in a long-lived context.
It is not clear why these were split out, but it probably had something to do with testing before storageList() could return NULL for an empty directory.
Also remove the tests that depended on a boolean return, which are no longer needed for coverage.
restoreRecoveryConf() and restoreRecoveryWriteConf() do enough work to deserve their own memory contexts.
restoreFilePgPath() was leaking a String every time it was called, which could be a lot.
Also fix a spacing issue.
These were not really leaks since memory was being freed by the calling function, but these functions do enough work to deserve their own memory contexts.
This was not really a leak since memory was being freed by the calling function, but this function does enough work to deserve its own memory context.
Also fixed a doubled semicolon.
