- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Tue, Apr 20
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.
Mon, Apr 19
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.
Thu, Apr 15
Let's see what happens in the discussion on llvm-dev before moving forward with this patch.
Wed, Apr 14
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.
Tue, Apr 13
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.
Mon, Apr 12
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.
Feb 18 2021
This commit introduced an unused variable warning when built without asserts. (CoverageMappingGen.cpp:984) I have fixed it with rG4544a63b7705.
Feb 17 2021
Thanks for the quick fix.
Feb 16 2021
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.
Feb 5 2021
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.
Jan 19 2021
Dec 21 2020
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.
Dec 15 2020
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.
Dec 14 2020
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.
Nov 13 2020
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.
Nov 3 2020
I can't speak to its technical correctness, but this is exactly the test I requested and it looks good at a high level.
Oct 17 2020
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.
Oct 16 2020
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:
Oct 13 2020
PowerPC still doesn't seem to be fixed as of 6713332fddb7. We have someone trying to narrow it down.
Oct 12 2020
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.)
Oct 9 2020
Oct 7 2020
Oct 5 2020
Sep 21 2020
Sep 10 2020
Sep 2 2020
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.
Aug 19 2020
Looks good from the FrameHeaderCache side.
Aug 18 2020
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?
Aug 16 2020
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.
Aug 6 2020
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."
Aug 4 2020
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.
Jul 17 2020
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.
Jul 14 2020
Jul 13 2020
Jun 15 2020
Jun 12 2020
Thanks for the quick response and easy deal. Looking forward to this relanding--it's a good change for sure.