♟ vitalybuka

Revert "[hwasan] print exact mismatch offset for short granules."

[scudo] Clang-format tests

Galina, please take a look. I believe it's sanitizers only, but maybe I am missing something.

[scudo] Fix test on arch without MTE

[scudo] Avoid ifdef in test

[scudo] Fix use of ScopedDisableMemoryTagChecks in test

[scudo] Enabled MTE before the first allocator

In D86669#2836130, @fhahn wrote:

getUnderlyingObjects already traverse large set on instructions so
there is no reason to limit some sequences by MaxLookup.

I am not sure I completely follow this reasoning. Even if it already traverses a large number of instructions, without the depth limit it will visit even more? Do you have any estimate on the impact in terms of extra work?

[NFC][sanitizer] Add newline at the end

[sanitizer] Add QEMU cleanup

[sanitizer] Fix compiler_rt_build cleanup

[sanitizer] Simplify clobbering

[sanitizer] Cleanup after build

Less builds for sanitizer-buildbot{2,8}

Reassign sanitizer builders/workers

[NFC] Reformat sanitizer workers

[NFC] Add getUnderlyingObjects test

comments and use DefaultConfig

Reason for revert: it introduced unexplained memory leak.

I've updated summary.
Could you "arc amend" to include it into your git commit.

In D101832#2820465, @MaskRay wrote:

In D101832#2736636, @MaskRay wrote:

I think @vitalybuka has concrete suggestion on the naming.

If ignorelist is used, I can delete -fsanitize-coverage-blocklist=

@kda I don't mind if we try to remove __asan_get_current_fake_stack in a separate patch

[NFC][sanitizer] Remove calls to __asan_get_current_fake_stack

I've updated the summary, usually shorter title of the git commit looks nicer.

use __builtin_frame_address

[asan] Remove Asan, Ubsan support of RTEMS and Myriad

[NFC] Fix "unused variable" warning

remove unrelated fix

[NFC][hwasan] Fix "implicitly declaring library function"

[lld][MachO] Fix UB after D103006

[NFC][sanitizer] clang-format some code

[NFC] Remove unused variable

In D104165#2814817, @stephan.yichao.zhao wrote:

In D104165#2814790, @vitalybuka wrote:

why __sanitizer_print_stack_trace is not enough?

We wanted to record stack traces to some databases for post-process. This is similar to the request of printing dfsan origin traces to a buffer.

why __sanitizer_print_stack_trace is not enough?

I'd prefer we just update __asan_get_current_fake_stack()

vitalybuka (Vitaly Buka)
User

Projects

User Details

Recent Activity
View All

Today

Yesterday

Tue, Jun 22

Mon, Jun 21

Fri, Jun 18

Thu, Jun 17

Wed, Jun 16

Tue, Jun 15

Mon, Jun 14

Fri, Jun 11

vitalybuka (Vitaly Buka)User