Use leak sanitizer instead of internal mdebug to check for memory leaks#9294
Use leak sanitizer instead of internal mdebug to check for memory leaks#9294levitte wants to merge 6 commits intoopenssl:masterfrom
Conversation
|
This also replaces #8323 |
|
fly-by-comment: typo in commit message title (and GitHub title): 'sasnitizer' |
Fixed I also changed the way it's enabled, as sufficiently old clang doesn't understand |
I think it should. The leak sanitizer gives far better output than our mdebug ever will. |
|
Travis failure looks relevant: |
|
Damn... |
|
Drop that platform out for this check. |
I am worried about corner cases for code paths that only happen on dropped platforms.... on the other hand, since this approach is clang/gcc centric already, maybe I worry too much. |
|
I'll rework this to avoid mingw... that will require some major surgery of the build matrix |
|
Are you still intending to drop the internal memory-leak tooling? I totally support that in favor of ASAN. ASAN is what everyone is doing. :) |
|
Yup, that's my intention. (that will be like closing a big circle, considering the mdebug stuff was my first commit as a team member, back almost exactly 20 years ago) |
|
BTW, I have no idea why mingw was mentioned at all here. The Travis failure happens on MacOS X. So, er, should we simply not do this on MacOS X? |
|
The MacOS problem has been complained about here: google/sanitizers#1026 |
|
When you remove the mdebug stuff, please also remove all the fault-insertion stuff in crypto/mem.c (shouldfail(), md_trace_fd, etc) |
|
I think we should just disable this on MacOS. |
23b6e49 to
812e328
Compare
|
I solved the MacOS case by not specifying |
|
Sorry, I couldn’t resist any longer 😉. |
|
That's all right. Thanks |
|
I'm pondering if I should add a test program that intentionally leaks memory, for demonstration purposes... |
paulidale
left a comment
There was a problem hiding this comment.
I'm inclined to think yes to the deliberately leaking test program.
We'd quickly find out if leak detection ever stopped working.
Detects if leak sanitizing is on, and directs the exit code accordingly. Note that this program is designed to fail when leaking, as that's expected, so to make it easy for wrapper scripts, we also make it look like it fails when sanitizing isn't on.
9695195 to
6707412
Compare
|
CIs are happy. Is @openssl happy? |
|
are you going to remove the current mdebug cruft? |
That's my intention, yes. |
|
... or... wanna take that on? I wouldn't mind. You do need to retain the public API, though... |
|
I will make a PR to remove the existing mem-debug stuff. I had wanted to remove the malloc-fail stuff as well, but it seems there's interest in this now. (I forget which comment in which PR) |
|
PR #10572 |
The leak sanitizer gives better reports (complete stack traces) and works as a wrapper around the application instead of relying on cooperative enabling and disabling calls (which are too easy to get unbalanced). Related to #8322 Reviewed-by: Paul Dale <[email protected]> (Merged from #9294)
Detects if leak sanitizing is on, and directs the exit code accordingly. Note that this program is designed to fail when leaking, as that's expected, so to make it easy for wrapper scripts, we also make it look like it fails when sanitizing isn't on. Reviewed-by: Paul Dale <[email protected]> (Merged from #9294)
|
yes, i rebased, took master for the conflicts, squashed, and pushed. i'll note that over there too. |
|
This doesn't actually seem to work in travis. The memleak test is failing in the extended tests. |
|
I'm proposing to temporarily revert this in #10689. |
The leak sanitizer gives better reports (complete stack traces) and
works as a wrapper around the application instead of relying on
cooperative enabling and disabling calls (which are too easy to get
unbalanced).
Related to #8322