This is an archive of the discontinued LLVM Phabricator instance.

[lsan] Move out suppression of invalid PCs from StopTheWorld
ClosedPublic

Authored by vitalybuka on Dec 7 2021, 10:48 PM.

Details

Summary

This removes the last use of StackDepot from StopTheWorld.

Depends on D115284.

Diff Detail

Event Timeline

vitalybuka requested review of this revision.Dec 7 2021, 10:48 PM
vitalybuka created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptDec 7 2021, 10:48 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
morehouse added inline comments.Dec 9 2021, 8:02 AM
compiler-rt/lib/lsan/lsan_common.cpp
184

We can use stack instead of StackDepotGet(stack_trace_id) to avoid another lookup. We can also then remove stack_trace_id from the parameter list.

552

I don't see these checks anywhere in SuppressInvalid. Why is it safe to omit them? Will we introduce new false negatives because we're suppressing more things?

morehouse accepted this revision.Dec 9 2021, 8:06 AM
morehouse added inline comments.
compiler-rt/lib/lsan/lsan_common.cpp
552

Never mind. I see now that CollectLeaksCb filters out things that don't meet these conditions:

if (!m.allocated()) return;
if (m.tag() == kDirectlyLeaked || m.tag() == kIndirectlyLeaked)
  leaks->push_back({chunk, m.stack_trace_id(), m.requested_size(), m.tag()});
This revision is now accepted and ready to land.Dec 9 2021, 8:06 AM
vitalybuka marked 3 inline comments as done.Dec 9 2021, 11:28 AM
morehouse accepted this revision.Dec 9 2021, 12:04 PM

For some reason this change makes Firefox Linux ASAN builds break our CI in a way that doesn't even leave logs (it looks like the workers completely die)

Herald added a project: Restricted Project. · View Herald TranscriptMar 18 2022, 2:16 PM

For some reason this change makes Firefox Linux ASAN builds break our CI in a way that doesn't even leave logs (it looks like the workers completely die)

Sorry, no sure what to do with available info.
Have you been able to solve the problem?

sbc100 added a subscriber: sbc100.May 19 2022, 5:24 PM
sbc100 added inline comments.
compiler-rt/lib/lsan/lsan_common.cpp
159

I ran into an issue with this change when attempting to upgrade compiler-rt in emscripten.

It seems that this function will always return 0 if stack traces are disabled by doing malloc_context_size=0/1 ?

This means that SuppressInvalid always returns true and therefore everything get suppressed and not report is generated at add.

We have been recommending malloc_context_size=0/1 as a way to speed up msan/lsan under emscripten but this change seems to mean that completely disabled lsan (no report generated at all).

Does lsan now require malloc_context_size of at least 2?

vitalybuka added inline comments.May 19 2022, 7:18 PM
compiler-rt/lib/lsan/lsan_common.cpp
159

Sounds like reasonable use-case. If so this is unintentional and we need to fix and add a regression test.
How sure you are that this is just from this patch? This function was already present. On a quick look

we had

uptr caller_pc = 0;
    if (stack_id > 0)
      caller_pc = GetCallerPC(StackDepotGet(stack_id));
    // If caller_pc is unknown, this chunk may be allocated in a coroutine. Mark
    // it as reachable, as we can't properly report its allocation stack anyway.
    if (caller_pc == 0 || (param->skip_linker_allocations &&
                           GetLinker()->containsAddress(caller_pc))) {
      m.set_tag(kIgnored);
      param->frontier->push_back(chunk);
    }

which I believe suppress report as well

sbc100 added inline comments.May 19 2022, 7:30 PM
compiler-rt/lib/lsan/lsan_common.cpp
159

Ah, I suppose it could have pre-dated this patch.

I know it used to work in LLVM 13 and stopped working when I updated to 14.