The assumption is that memory still reachable at program termination, but not deallocated, has not leaked. And it is how all three of LSAN, Valgrind, and HeapLeakChecker define it.

Thanks for the review. I reworked to take a somewhat different approach--this improves the printer itself to tolerate the situation quite a bit better. But I have included your improved comment at the decision point.

Dramatically rework the last attempt.

Let's see what happens in the discussion on llvm-dev before moving forward with this patch.

I have tracked the asan build bot breakage to this change. See below.

I have opened the discussion on llvm-dev. I do want to find a solution that everyone can live with, and I apologize that it felt like Google was stepping over its bounds.

Another question to ask is:

I think it is a valid transformation.

I went ahead and reverted. We can discuss a plan--hopefully the internal cleanup to obviate this will go smoothly.

I don't know why the various people you added didn't respond. This is unfortunate.

I'm also having problems with this commit, only I'm seeing it without assertions. Working on a smaller repro, but will revert soon.

This change breaks llvm-project/clang-tools-extra/clangd/tool/ClangdMain.cpp:570:11: error: enumeration value 'None' not handled in switch [-Werror,-Wswitch]. I would fix forward, but the solution is not obvious to me.

This commit introduced an unused variable warning when built without asserts. (CoverageMappingGen.cpp:984) I have fixed it with rG4544a63b7705.

Thanks for the quick fix.

this is as small as llvm-reduce makes the ir:

Reverted in 5aa8f4c0843a68a24cb37dce5c0248c849d7d476

Unfortunately, this commit causes a segfault with the test case below. I'm intend to revert it shortly.

In D96167#2545911, @mgorny wrote:

Ok, now it's a definite improvement.

Still 4 sub-tests fail for me:

FAIL: /tmp/portage/sys-libs/libcxx-12.0.0_rc1/work/libcxx/test/libcxx/gdb/gdb_pretty_printer_test.sh.cpp:611
GDB printed:
   'Traceback (most recent call last):\n  File "/tmp/portage/sys-libs/libcxx-12.0.0_rc1/work/libcxx/test/libcxx/gdb/../../../utils/gdb/libcxx/printers.py", line 315, in to_string\n    usecount = refcount["__shared_owners_"] + 1\ngdb.error: There is no member named __shared_owners_.\n'
Value should match:
   'std::shared_ptr<int> count 2, weak 0 containing = {__ptr_ = 0x[a-f0-9]+}'
FAIL: /tmp/portage/sys-libs/libcxx-12.0.0_rc1/work/libcxx/test/libcxx/gdb/gdb_pretty_printer_test.sh.cpp:616
GDB printed:
   'Traceback (most recent call last):\n  File "/tmp/portage/sys-libs/libcxx-12.0.0_rc1/work/libcxx/test/libcxx/gdb/../../../utils/gdb/libcxx/printers.py", line 315, in to_string\n    usecount = refcount["__shared_owners_"] + 1\ngdb.error: There is no member named __shared_owners_.\n'
Value should match:
   'std::shared_ptr<int> count 3, weak 0 containing = {__ptr_ = 0x[a-f0-9]+}'
FAIL: /tmp/portage/sys-libs/libcxx-12.0.0_rc1/work/libcxx/test/libcxx/gdb/gdb_pretty_printer_test.sh.cpp:622
GDB printed:
   'Traceback (most recent call last):\n  File "/tmp/portage/sys-libs/libcxx-12.0.0_rc1/work/libcxx/test/libcxx/gdb/../../../utils/gdb/libcxx/printers.py", line 315, in to_string\n    usecount = refcount["__shared_owners_"] + 1\ngdb.error: There is no member named __shared_owners_.\n'
Value should match:
   'std::shared_ptr<int> count 3, weak 1 containing = {__ptr_ = 0x[a-f0-9]+}'
FAIL: /tmp/portage/sys-libs/libcxx-12.0.0_rc1/work/libcxx/test/libcxx/gdb/gdb_pretty_printer_test.sh.cpp:627
GDB printed:
   'Traceback (most recent call last):\n  File "/tmp/portage/sys-libs/libcxx-12.0.0_rc1/work/libcxx/test/libcxx/gdb/../../../utils/gdb/libcxx/printers.py", line 315, in to_string\n    usecount = refcount["__shared_owners_"] + 1\ngdb.error: There is no member named __shared_owners_.\n'
Value should match:
   'std::shared_ptr<int> count 3, weak 0 containing = {__ptr_ = 0x[a-f0-9]+}'

In D96167#2545870, @mgorny wrote:

I haven't tested it on main but on top of 12.0.0-rc1:

Undo an auto-lint fix that breaks the string.

This patch does fix several problems we noticed at Google that were created by the previous patch. I'm not qualified to judge the technical approach, without this, asan is completely broken on powerpc, so that speaks strongly in its favor.

In D93130#2455145, @ldionne wrote:

In D93130#2453963, @saugustine wrote:

This change appears to have dropped a constructor, or maybe two. I'm not familiar enough with all the requirements to know if that is correct or not. Here is a somewhat redacted version of the errors I get building a private application.
...

Is it possible that your custom Allocator has its converting copy constructor (from other specializations of Allocator) marked as explicit? We don't seem to have a test for that, I'll add one and fix this, but please confirm that it's the case.

This change appears to have dropped a constructor, or maybe two. I'm not familiar enough with all the requirements to know if that is correct or not. Here is a somewhat redacted version of the errors I get building a private application.

The reason this hasn't been run by default is due to python versioning issues with gdb, the system it runs on, and the tests themselves. There are certain cross-platform issues as well.

I can't speak to its technical correctness, but this is exactly the test I requested and it looks good at a high level.

Filed https://bugs.llvm.org/show_bug.cgi?id=47891 to continue discussion.

Filed https://bugs.llvm.org/show_bug.cgi?id=47891 to continue discussion.

Here is a relatively simple, self-contained testcase. Of interest is that the entire loop needs to be present, and completely unwound for this bug to show. It looks to me like either next_carry or carry is mis-calculated or stale on the ninth iteration which fills the second-to-last element.

I spoke too soon. Disabling optimization on that function does fix the problem, but its input and output is all the same. So the miscompile must just not get tickled by that. Will dig a little deeper.

The miscompiled function is probably:

It is a miscompile--or, at least a fingerprint is being miscomputed. The failure check is here:

PowerPC still doesn't seem to be fixed as of 6713332fddb7. We have someone trying to narrow it down.

Google has tracked down a failure in openssl for powerpc to this change. (And the fix for the 32-bit vs 64-bit issue below doesn't seem to fix this.)

I am going to accept this, since no one else seems to be able to review it. But the problem here is that no one really knows what a simplified ifdef chain with the same functionality looks like. I tried a couple of times and failed miserably.

Looks good from the FrameHeaderCache side.

Update for comment.

Now just waiting on a libunwind group reviewer.

Rework to match bsd workaround.

In D75954#2223238, @hans wrote:

In D75954#2220392, @saugustine wrote:

In D75954#2219870, @dim wrote:

It looks like the need for some locking in this FrameHeaderCache was completely overlooked? Or at least, having a cache per thread would make locking unnecessary, but it would cost more memory.

Well, not _completely_ overlooked. Looks like glibc locks things and other libc's don't. Should be easy to add a lock here for non glibc targets.

Sterling, do you think this will be fixed soon so we can get it in the llvm 11 release?

In D75954#2219870, @dim wrote:

It looks like the need for some locking in this FrameHeaderCache was completely overlooked? Or at least, having a cache per thread would make locking unnecessary, but it would cost more memory.

This change has a subtle isse with wattr_get and friends: saved_opts isn't actually used, and the documentation for them says to always pass a nullptr. "The parameter opts is reserved for future use, applications must supply a null pointer."

The darwin-dsymutil.c tests this code path right now on line 33. I found this error by running it under asan; otherwise it was fully latent.

This is a reasonable workaround, as it seems to be checking the position of various arguments, and as things work today, lgcc and the compiler-rt variants appear in exactly the same places.

Thanks for the quick response and easy deal. Looking forward to this relanding--it's a good change for sure.