Do not destruct static maps.
In case they are deleted while some threads are using them (this
happens sometimes depending on how these libraries are loaded and how
they are being used).
Noting that b/69122224 is filed to move these into functions.
Bug: 129726097
Test: HIDL's run_all_device_tests.sh
Test: no longer see error where it repro'd before:
FORTIFY: pthread_mutex_lock called on a destroyed mutex
Change-Id: I66eb9aa24e31d7fc652f0426361c17600b4716ec
diff --git a/transport/HidlTransportSupport.cpp b/transport/HidlTransportSupport.cpp
index 16f47c6..846b166 100644
--- a/transport/HidlTransportSupport.cpp
+++ b/transport/HidlTransportSupport.cpp
@@ -88,9 +88,9 @@
// Due to ABI considerations, IBase cannot have a destructor to clean this up.
// So, because this API is so infrequently used, (expected to be usually only
// one time for a process, but it can be more), we are cleaning it up here.
- std::unique_lock<std::mutex> lock = details::gServicePrioMap.lock();
- pruneMapLocked(details::gServicePrioMap);
- details::gServicePrioMap.setLocked(service, {policy, priority});
+ std::unique_lock<std::mutex> lock = details::gServicePrioMap->lock();
+ pruneMapLocked(details::gServicePrioMap.get());
+ details::gServicePrioMap->setLocked(service, {policy, priority});
return true;
}
@@ -104,9 +104,9 @@
// Due to ABI considerations, IBase cannot have a destructor to clean this up.
// So, because this API is so infrequently used, (expected to be usually only
// one time for a process, but it can be more), we are cleaning it up here.
- std::unique_lock<std::mutex> lock = details::gServiceSidMap.lock();
- pruneMapLocked(details::gServiceSidMap);
- details::gServiceSidMap.setLocked(service, requesting);
+ std::unique_lock<std::mutex> lock = details::gServiceSidMap->lock();
+ pruneMapLocked(details::gServiceSidMap.get());
+ details::gServiceSidMap->setLocked(service, requesting);
return true;
}