[CXX-829] ASAN build should not shut down libmognoc as it creates false positive leaks Created: 22/Jan/16  Updated: 19/Sep/16  Resolved: 12/Sep/16

Status: Closed
Project: C++ Driver
Component/s: Build
Affects Version/s: None
Fix Version/s: 3.0.2

Type: Task Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: Andrew Morrow (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

https://evergreen.mongodb.com/task/mongodb_cpp_driver_dev_ubuntu1410_debug_asan_compile_and_test_472f3673ee507505671a566d696b0fc1f271179a_16_01_22_21_27_46

We know these aren't real, but we aren't getting enough symbolized stack trace to write a suppression.



 Comments   
Comment by Githook User [ 12/Sep/16 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@mongodb.com'}

Message: CXX-829 Avoid mongoc cleanup for ASAN build
Branch: master
https://github.com/mongodb/mongo-cxx-driver/commit/252689a7df298957fc74c9698d3e3fed8e037fa9

Comment by Andrew Morrow (Inactive) [ 12/Sep/16 ]

The leaks we were observing go away if no call is made to mongoc_cleanup. The theory is that mongoc_cleanup is calling a cleanup function for one of its dependent libraries (maybe SASL?), which then dlcloses some library. There were heap allocations in that library that were stored in static pointers. As long as the libraries were loaded, the leak detector would see those allocations as rooted somewhere, but after the library was unloaded, they were no longer rooted, so they looked like leaks. However, since the library was no longer loaded, ASAN couldn't give a helpful stack trace and tell us what library it was in. Suppressing the call to mongoc_cleanup seems to make the issue go away.

Comment by Andrew Morrow (Inactive) [ 10/Sep/16 ]

https://github.com/mongodb/mongo-cxx-driver/pull/527

Comment by Andrew Morrow (Inactive) [ 19/Feb/16 ]

Not required for 3.0.1, kicking out to 3.0.2

Generated at Wed Feb 07 22:00:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.