- User Since
- Mar 10 2016, 1:50 PM (274 w, 2 d)
why __sanitizer_print_stack_trace is not enough?
I'd prefer we just update __asan_get_current_fake_stack()
Thu, Jun 10
I see comment on the D104091
LGTM with some nits and if you extract FunctionStackPoisoner::initializeCallbacks into a separate patch
Wed, Jun 9
Tue, Jun 8
LGTM but upstream testing could be very helpful for those who change code without TrustyOS setup
Thanks. LGTM with some nits.
Mon, Jun 7
Sorry, this thread slipped from me. I assume it's already resolved?
For this reason I filed https://bugs.llvm.org/show_bug.cgi?id=45397
It's not helpful if it's spamming committers of unrelated changes. I don't
remember but it was probably broken for some time, otherwise I would
probably try to bisect.
I am fine with up to 10 :)
I looked up all calls to this function and we use this function once per thread, I don't see a point in this caching
Following should be enough and solve symbols issues.
This patch introduce https://lab.llvm.org/buildbot/#/builders/85/builds/4886
Correct, at that time I thought we are doing WEAK asan_use_after_return_mode, for which new fictions are not needed.
Sorry, we'd save some time if I asked to drop asan_use_after_return_mode instead.
If you are going to recover that one I'd recommencement Flagless -> Always to be consistent with naming?
Sat, Jun 5
Oh, I missed
Yes, it was a problem on my end, all good now.
Fri, Jun 4
I looked at Lazy approach and it's simpler then I thought. Asan already contains all needed pieces.
Considering that we have not idea how to handle Windows and Darwin we should do that in this patch.
Upload the last reverted version
I stated that as a fix for DCHECK, but then I noticed that you already landed the fix.
However then I noticed .data() on just created string is still kind of not nice even if it has no DCHECK there.
Please stamp this one to avoid conflicts with D103725
undo accidental change
undo accidental line move