Fix GDTCORDirectorySizeTracker crash

[paulb777]

Log error to help debug firebase/firebase-ios-sdk#15414

[google-oss-bot]

Coverage Report ¹

Affected Products

• GoogleDataTransport-ios-GoogleDataTransport.framework

  Overall coverage changed from 50.40% (17eb3cb) to 63.10% (a2631f8) by +12.70%.

  28 individual files with coverage change

  Filename	Base (17eb3cb)	Merge (a2631f8)	Diff
  GDTCCTCompressionHelper.m	81.63%	0.00%	-81.63%
  GDTCCTNanopbHelpers.m	56.30%	0.00%	-56.30%
  GDTCCTUploader.m	91.33%	54.00%	-37.33%
  GDTCCTUploadOperation.m	90.77%	28.41%	-62.36%
  GDTCCTURLSessionDataResponse.m	100.00%	0.00%	-100.00%
  GDTCORAssert.m	0.00%	88.89%	+88.89%
  GDTCORClock.m	70.24%	85.71%	+15.48%
  GDTCORConsoleLogger.m	20.00%	76.00%	+56.00%
  GDTCORDirectorySizeTracker.m	67.27%	93.44%	+26.17%
  GDTCOREvent+GDTCCTSupport.m	35.05%	0.00%	-35.05%
  GDTCOREvent+GDTMetricsSupport.m	75.00%	0.00%	-75.00%
  GDTCOREvent.m	60.92%	97.70%	+36.78%
  GDTCORFlatFileStorage+Promises.m	18.97%	46.55%	+27.59%
  GDTCORFlatFileStorage.m	21.38%	91.04%	+69.65%
  GDTCORLifecycle.m	39.24%	54.43%	+15.19%
  GDTCORLogSourceMetrics.m	52.63%	93.86%	+41.23%
  GDTCORMetrics+GDTCCTSupport.m	93.75%	0.00%	-93.75%
  GDTCORMetrics.m	47.27%	40.00%	-7.27%
  GDTCORMetricsController.m	15.88%	94.71%	+78.82%
  GDTCORMetricsMetadata.m	0.00%	100.00%	+100.00%
  GDTCORPlatform.m	59.35%	72.26%	+12.90%
  GDTCORProductData.m	40.54%	83.78%	+43.24%
  GDTCORRegistrar.m	76.88%	79.57%	+2.69%
  GDTCORStorageMetadata.m	0.00%	100.00%	+100.00%
  GDTCORTransformer.m	0.00%	91.09%	+91.09%
  GDTCORTransport.m	0.00%	84.09%	+84.09%
  GDTCORUploadBatch.m	100.00%	0.00%	-100.00%
  GDTCORUploadCoordinator.m	62.00%	80.00%	+18.00%

Test Logs

• Base (17eb3cb): https://github.com/google/GoogleDataTransport/actions/runs/20045509548
• Merge (a2631f8): https://github.com/google/GoogleDataTransport/actions/runs/20047198145

1. https://storage.googleapis.com/firebase-sdk-metric-reports/UjlzJJfGLY.html

[ncooke3]

Based on the trace firebase/firebase-ios-sdk#15414 (comment), we crash on enumeration due to a non-recoverable error in malloc, so we won't get to the error handler.

So I don't think we should change the error handler's return value because it could affect behavior in other cases and result in inaccurate sizing.

This won't fix the crash but we could log the error in the handler. It's possibly it could help further debugging.

If memory is corrupted from somewhere else, looping over the file system may be what is increasing the odds of trying to allocate this corrupted memory.

I audited how we use nanopb (C) and didn't find any memory vulnerabilites.