This is an archive of the discontinued LLVM Phabricator instance.

[LLDB] Fix assertion failure by removing `CopyType` in `std::coroutine_handle` pretty printer
ClosedPublic

Authored by avogelsgesang on Feb 1 2023, 5:52 PM.

Details

Summary

The pretty printer for std::coroutine_handle was running into

Assertion failed: (target_ctx != source_ctx && "Can't import into itself")

from ClangASTImporter.h, line 270.

This commit fixes the issue by removing the CopyType call from the
pretty printer. While this call was necessary in the past, it seems to
be no longer required, at least all test cases are still passing. Maybe
something changed in the meantime around the handling of TypesystemClang
instances. I don't quite understand why CopyType was necessary earlier.

I am not sure how to add a regression test for this, though. It seems
the issue is already triggered by the exising TestCoroutineHandle.py,
but API tests seem to ignore all violations of lldbassert and still
report the test as "passed", even if assertions were triggered

Diff Detail

Event Timeline

avogelsgesang created this revision.Feb 1 2023, 5:52 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 1 2023, 5:52 PM
Herald added a subscriber: ChuanqiXu. · View Herald Transcript
avogelsgesang requested review of this revision.Feb 1 2023, 5:52 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 1 2023, 5:52 PM

This change makes me a little nervous, but mostly because I don't quite understand the design here.
So ASTImporter does not have a check whether src context and dst context are identical?

avogelsgesang added a comment.EditedFeb 2 2023, 1:33 PM

This change makes me a little nervous, but mostly because I don't quite understand the design here.
So ASTImporter does not have a check whether src context and dst context are identical?

I am completely with you. I also don't understand the design of ASTImporter.
I had to learn the hard way that there are multiple ASTs around at the same time (one per object file + one for the "debugging session" in which all temporary types etc. are created).
But I don't quite understand their lifetimes, and which types of cross-AST linking are supported and in which cases types need to be copied over.

In that sense, I see this commit mostly as a basis for discussions, but I am not completely confident that this is the right solution. I would hope to find someone more experienced with lldb who can point me in the right direction :)

labath accepted this revision.Feb 3 2023, 3:57 AM

Well.. I don't believe we have any ASTImporter calls in any of the other pretty printers, so I think this change is good. And if it causes some other issues, then maybe we need to look at solving them in some other way...

This revision is now accepted and ready to land.Feb 3 2023, 3:57 AM
avogelsgesang added a comment.EditedFeb 3 2023, 5:34 AM

Agree, other pretty-printers also don't use ASTImporter. I think the call was still needed originally in https://github.com/llvm/llvm-project/commit/01f4c305fae9ff2f165ce0f635a90f8e2292308c, because the promise_type was combined with newly created AST types which were created in a different AST-instance (see GetCoroutineFrameType in this old version of the code). My interpretation now is: Building struct types which refer to types from other AST instances is not supported. Returning synthetic children with types from different ASTs is supported, thoguh.

I will wait until Wednesday morning before merging this fix, to give other potentially interested reviewers some time. After merging this to main, I will open a backport request for LLDB-16.

I am still a bit concerned that the lldbassert was not caught by the existing tests. It seems the tests are ignoring lldbassert given that those asserts only print some information to stderr but don't actually terminate lldb? I assume this is something which should be fixed globally for all API test? Do you have an idea how I could fix this?

aprantl accepted this revision.Feb 3 2023, 10:13 AM

Well.. I don't believe we have any ASTImporter calls in any of the other pretty printers, so I think this change is good. And if it causes some other issues, then maybe we need to look at solving them in some other way...

Okay I guess I can live with that reasoning ...

@labath @aprantl Thanks for your reviews! I would like to backport this fix together with the fix from https://reviews.llvm.org/D132815 to the 16.0 release branch now. For that I would need your approval on https://github.com/llvm/llvm-project-release-prs/pull/254