rupprecht added a comment. In D87637#2395246 <https://reviews.llvm.org/D87637#2395246>, @teemperor wrote:
> I'm late to the party, but I actually don't think this is a good change as it > disables the normal LLDB backtraces. The current test errors we see on Green > Dragon look now like this: > > Assertion failed: (size() >= N && "Dropping more elements than exist"), > function drop_front, file > /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/ADT/StringRef.h, > line 655. > Fatal Python error: Aborted > > Current thread 0x000000010e0f9dc0 (most recent call first): > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lib/python3.7/site-packages/lldb/__init__.py", > line 2717 in HandleCommand > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", > line 2129 in runCmd > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/commands/apropos/with-process/TestAproposWithProcess.py", > line 43 in test_apropos_with_process > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/third_party/Python/module/unittest2/unittest2/case.py", > line 413 in runMethod > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/third_party/Python/module/unittest2/unittest2/case.py", > line 383 in run > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/third_party/Python/module/unittest2/unittest2/case.py", > line 458 in __call__ > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/third_party/Python/module/unittest2/unittest2/suite.py", > line 117 in _wrapped_run > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/third_party/Python/module/unittest2/unittest2/suite.py", > line 115 in _wrapped_run > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/third_party/Python/module/unittest2/unittest2/suite.py", > line 85 in run > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/third_party/Python/module/unittest2/unittest2/suite.py", > line 66 in __call__ > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/third_party/Python/module/unittest2/unittest2/runner.py", > line 165 in run > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py", > line 1017 in run_suite > File > "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/dotest.py", > line 7 in <module> > > It's practically impossible to say from the backtrace which commit is to > blame for the crash as I only know we run the command `apropos env` and then > we crash in StringRef. > > Do we have a way of getting both the LLVM and the Python backtrace? I'm not really sure what you mean by the LLDB backtrace or how this is inhibiting it. IIUC, the faulthandler here is triggered when the test *receives* a signal killing it (e.g. if it hangs and lit or whatever kills it after some timeout). If the LLDB process that this calls crashes, it shouldn't affect that. SWIG maybe is complicating things here. Do you have a way to reproduce the issue you're talking about? e.g. "git checkout <bad commit> && ninja check-lldb-api"? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87637/new/ https://reviews.llvm.org/D87637 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
