Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.4(EOL), 10.5
-
None
Description
28049e0d5b26528175051c8deed96b380518b9a6 |
> ./mysql-test/mtr spider/odbc/pg.basic_sql
|
....
|
MariaDB Version 10.4.26-17-MariaDB-debug
|
- SSL connections supported
|
- binaries are debug compiled
|
- binaries built with wsrep patch
|
Collecting tests...
|
Installing system database...
|
|
==============================================================================
|
|
TEST RESULT TIME (ms) or COMMENT
|
--------------------------------------------------------------------------
|
|
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
|
spider/odbc/pg.basic_sql [ pass ] 3185
|
***Warnings generated in error logs during shutdown after running tests: spider/odbc/pg.basic_sql
|
|
==148932==ERROR: LeakSanitizer: detected memory leaks
|
SUMMARY: AddressSanitizer: 7646314 byte(s) leaked in 3204 allocation(s).
|
|
--------------------------------------------------------------------------
|
The servers were restarted 0 times
|
Spent 3.185 of 8 seconds executing testcases
|
|
Warnings in log: All 1 tests were successful.
|
|
Errors/warnings were found in logfiles during server shutdown after running the
|
following sequence(s) of tests:
|
spider/odbc/pg.basic_sql
|
mysql-test-run: *** ERROR: There where errors/warnings in server logs after running test cases.
|
Any other MTR test case in the spider/odbc/pg suite results in memory leaks.
Attachments
Issue Links
- relates to
-
MDEV-29579 Connect engine ASAN failures
-
- Closed
-
I was able to eliminate more leaks, but to get rid of all of them is rather tricky without a proper stack. See the commit
upstream/10.5-enterprise-ment-1591-unleak-some 45f4885b3e4a5d72bb7fb7e822eca60e908fe7ac
MENT-1591 [demo] reduce some leaking.
Take spider/odbc/mariadb.basic_sql for example:
Before this change:
SUMMARY: AddressSanitizer: 9496362 byte(s) leaked in 4532 allocation(s).
After adding the first hunk (calling SQLFreeHandle()):
SUMMARY: AddressSanitizer: 687962 byte(s) leaked in 3678 allocation(s).
After removing the dbug_off code:
SUMMARY: AddressSanitizer: 604162 byte(s) leaked in 708 allocation(s).
Unfortunately without a better stack reported from leaksanitizer it is
hard to figure out where the remaining leaks come from.
I found a slack thread about similar leaks in CONNECT, and applying the UNIQUE part of the patch of
MDEV-29579(thanks to Johnston for pointing me to the commit), the leak all disappeared, even without applying the changes in the above commit. So it seems that libodbc does its own cleanup of allocated SQLHandle objects somehow.upstream/10.5-enterprise-ment-1591 1cd637149dfdde385006d8b5801859cd3aa68d78
MENT-1591 Keep spider in memory until exit in ASAN builds
Same as MDEV-29579. For some reason, libodbc does not clean up
properly if unloaded too early with the dlclose() of spider. So we add
UNIQUE symbols to spider so the spider does not reload in dlclose().
However, with this change we get failures in the three ha_part tests in asan builds, see for example
https://buildbot.mariadb.org/#/builders/588/builds/3355
And the failure do not occur when running these tests separately / sequentially, but they do reproduce when run locally in parallel with other spider tests.
I also added some trivial leak in spider, to see whether it gets masked by the above change, and the answer is no, the leak is still reported:
upstream/10.5-enterprise-ment-1591-trivial-leak 337c253c5a30acfb138edfc45059192fd7a2c3b6
MENT-1591 [demo] Leaks still detected after adding the UNIQUE symbols
With the change that adds the UNIQUE symbols (see the parent commit
fd3ccb216baba01adfd3fe36fc10713c94027452), leaks are still detected.
This suggests libodbc does its own cleanup of all allocated SQLHandles
etc.
So this fix looks good so far, except the CI failures mentioned above.