Page MenuHomePhabricator

[lldb] [test] Workaround symlink-related test failures
ClosedPublic

Authored by mgorny on Feb 22 2021, 2:43 PM.

Details

Summary

Use realpath() when spawning the executable create_after_attach
to workaround a FreeBSD plugin (and possibly others) problem.
If the executable is started via a path containing a symlink, it is
added to the module list twice -- via the real and apparent path.
This in turn cases the requested breakpoint to resolve twice.

Use realpath() for main program path in lldb-vscode breakpoint tests
to workaround a similar problem. If the passed path does not match
the realpath, lldb-vscode does not report the breakpoints as verified
and causes tests to fail.

Since the underlying problems are non-trivial to fix and the purpose
of these tests is not to reproduce symlink problems, let's apply
trivial workarounds to make them pass.

Diff Detail

Event Timeline

mgorny created this revision.Feb 22 2021, 2:43 PM
mgorny requested review of this revision.Feb 22 2021, 2:43 PM
mgorny updated this revision to Diff 325870.Feb 23 2021, 12:19 PM
mgorny retitled this revision from [lldb] [test] Workaround symlink-related create_after_attach test failure to [lldb] [test] Workaround symlink-related test failures.
mgorny edited the summary of this revision. (Show Details)

Added a similar hack for tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py test.

I think it's valuable to avoid testing this (symlink issue) as a side effect of these test cases, but we should have an explicit test for this; it is an issue users could hit.

Do you know if this is a bug specific to lldb's FreeBSD code (or do we just have a default symlink in the paths used here where other OS's don/t)?

I think it's valuable to avoid testing this (symlink issue) as a side effect of these test cases, but we should have an explicit test for this; it is an issue users could hit.

Do you know if this is a bug specific to lldb's FreeBSD code (or do we just have a default symlink in the paths used here where other OS's don/t)?

I think the issue may be more widespread but I need to test. The module list problem probably depends on dyld behavior but I suppose lldb-vscode may be generic.

OK; I think this change is reasonable, I just want to make sure we don't completely lose the underlying issue.

Let's make sure that we at least have a bug report to track it (i.e., let's not close llvm.org/pr48376 and llvm.org/pr48421 with "no longer fails" without having a new bug for this problem)

labath accepted this revision.Mar 1 2021, 5:24 AM

Sounds reasonable. Having a canonical bug for the symlink issue would be reasonable too...

This revision is now accepted and ready to land.Mar 1 2021, 5:24 AM
This revision was landed with ongoing or failed builds.Mar 1 2021, 7:24 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 1 2021, 7:24 AM
mgorny added a comment.Mar 2 2021, 6:23 AM

I've edited both bugs (https://bugs.llvm.org/show_bug.cgi?id=48421 and https://bugs.llvm.org/show_bug.cgi?id=48376) to cover the generic problem. I can't promise I'll have time to work on them in the next ~2 months but if you have any suggestion how to solve them, I can try looking at them as time permits.