[lldb-dev] [Bug 47522] New: Assertion `isHandleInSync() && "invalid iterator access!"' failed

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47522

Bug ID: 47522
   Summary: Assertion `isHandleInSync() && "invalid iterator
access!"' failed
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: dmanti...@yandex.ru
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

Attempt to complete symbol name produces the following crash:

sysroot@/home/antipov/llvm> /home/antipov/.local/llvm-devel-12.0.0/bin/lldb
/home/antipov/.local/llvm-devel-12.0.0/bin/clang
(lldb) target create "/home/antipov/.local/llvm-devel-12.0.0/bin/clang"
Current executable set to '/home/antipov/.local/llvm-devel-12.0.0/bin/clang'
(x86_64).
(lldb) breakpoint set -f Gnu.cpp -l 1958
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) process launch -- -xc++ /dev/null
Process 1028276 launched: '/home/antipov/.local/llvm-devel-12.0.0/bin/clang'
(x86_64)
1 location added to breakpoint 1
Process 1028276 stopped
* thread #1, name = 'clang', stop reason = breakpoint 1.1
frame #0: 0x7693c6ac
libclang-cpp.so.12git`clang::driver::toolchains::Generic_GCC::GCCInstallationDetector::init(this=0x00499aa0,
TargetTriple=, Args=, ExtraTripleAliases=(Data =
0x, Length = 0)) at Gnu.cpp:1958:12
   1955 }
   1956 for (StringRef Suffix : CandidateBiarchLibDirs) {
   1957   const std::string LibDir = Prefix + Suffix.str();
-> 1958   if (!D.getVFS().exists(LibDir))
   1959 continue;
   1960   for (StringRef Candidate : CandidateBiarchTripleAliases)
   1961 ScanLibDirForGCCTriple(TargetTriple, Args, LibDir, Candidate,
(lldb) p Can[THEN PRESS TAB HERE]

==>

lldb: /home/antipov/llvm/source/llvm/include/llvm/ADT/DenseMap.h:1263:
DenseMapIterator
&llvm::DenseMapIterator,
llvm::detail::DenseMapPair,
false>::operator++() [KeyT = clang::DeclarationName, ValueT =
clang::StoredDeclsList, KeyInfoT = llvm::DenseMapInfo,
Bucket = llvm::detail::DenseMapPair, IsConst = false]: Assertion `isHandleInSync() &&
"invalid iterator access!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0.  Program arguments: /home/antipov/.local/llvm-devel-12.0.0/bin/lldb
/home/antipov/.local/llvm-devel-12.0.0/bin/clang 
1.  :1:1: current parser token 'Can'
2.  :42:1: parsing function body
'clang::driver::toolchains::Generic_GCC::GCCInstallationDetector::$__lldb_expr'
3.  :42:1: in compound statement ('{}')
 #0 0x7f0367b537b3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
/home/antipov/llvm/source/llvm/lib/Support/Unix/Signals.inc:563:13
 #1 0x7f0367b51b00 llvm::sys::RunSignalHandlers()
/home/antipov/llvm/source/llvm/lib/Support/Signals.cpp:71:18
 #2 0x7f0367b53ae5 SignalHandler(int)
/home/antipov/llvm/source/llvm/lib/Support/Unix/Signals.inc:0:3
 #3 0x7f0371c0da90 __restore_rt (/lib64/libpthread.so.0+0x14a90)
 #4 0x7f0366ab89e5 raise (/lib64/libc.so.6+0x3c9e5)
 #5 0x7f0366aa1895 abort (/lib64/libc.so.6+0x25895)
 #6 0x7f0366aa1769 _nl_load_domain.cold (/lib64/libc.so.6+0x25769)
 #7 0x7f0366ab0e76 (/lib64/libc.so.6+0x34e76)
 #8 0x7f036dd8af09 llvm::DenseMapIterator,
llvm::detail::DenseMapPair,
false>::operator!=(llvm::DenseMapIterator,
llvm::detail::DenseMapPair,
true> const&) const
/home/antipov/llvm/source/llvm/include/llvm/ADT/DenseMap.h:1257:5
 #9 0x7f036dd8af09 clang::DeclContext::all_lookups_iterator::operator++()
/home/antipov/llvm/source/llvm/tools/clang/include/clang/AST/DeclLookups.h:54:17
#10 0x7f036e8300fd (anonymous
namespace)::LookupVisibleHelper::lookupInDeclContext(clang::DeclContext*,
clang::LookupResult&, bool, bool)
/home/antipov/llvm/source/llvm/tools/clang/lib/Sema/SemaLookup.cpp:0:36
#11 0x7f036e82f984 (anonymous
namespace)::LookupVisibleHelper::lookupInScope(clang::Scope*,
clang::LookupResult&, (anonymous namespace)::UnqualUsingDirectiveSet&)
/home/antipov/llvm/source/llvm/tools/clang/lib/Sema/SemaLookup.cpp:0:9
#12 0x7f036e824f4f
std::__cxx11::list,
llvm::DenseMapInfo,
llvm::detail::DenseMapPair > >,
std::allocator,
llvm::DenseMapInfo,
llvm::detail::DenseMapPair > > > >::pop_back()
/usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/stl_list.h:1247:55
#13 0x7f036e824f4f (anonymous
namespace)::ShadowContextRAII::~ShadowContextRAII()
/home/antipov/llvm/source/llvm/tools/clang/lib/Sema/SemaLookup.cpp:3603:24
#14 0x7f036e824f4f (anonymous
namespace)::LookupVisibleHelper::lookupVisibleDecls(clang::Sema&,
clang::Scope*, clang::Sema::LookupNameKind, bool)
/home/antipov/llvm/source/llvm/tools/clang/lib/Sema/SemaLookup.cpp:3683:3
#15 0x7f036e824f4f clang::Sema::LookupVisibleDecls(clang::Scope*,
clang::Sema::LookupNameKind, clang::Visible

[lldb-dev] [Bug 47524] New: Calling functions with a null pointer-to-typedef-of-anonymous-struct argument fail

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47524

Bug ID: 47524
   Summary: Calling functions with a null
pointer-to-typedef-of-anonymous-struct argument fail
   Product: lldb
   Version: 11.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ja...@google.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

The LLDB expression evaluator fails to evaluate a function call
with a null argument of the pointer to typedef of anonymous struct type.
See below for detailed repro steps. The error message is:

```
error: function 'f' is used but not defined in this translation unit, and
cannot be defined in any other translation unit because its type does not have
linkage
```

The problem reproduces on the latest master as well as on LLDB 9 and 10 (have
not tried 11). 

It is also interesting to note that the problem goes away after the first
evaluation of the function call with non-null argument (as shown in the
example below). The problem also goes away if I make the struct non-anonymous.

```
$ cat a.cc
typedef struct {
  int f;
} S;

S s;

int f(S* s) {
  return s == nullptr;
}

int main() {
  return f(nullptr);  // break here, evaluate `f(nullptr)`
}

$ clang -g a.cc
$ lldb --version
lldb version 12.0.0
  clang revision 687e1d7121645d23aa5e919ed4d3c0e57af975cd
  llvm revision 687e1d7121645d23aa5e919ed4d3c0e57af975cd
$ lldb a.out
...
(lldb) b main
...
(lldb) r
...
-> 12 return f(nullptr);
...
(lldb) p f(nullptr)
error: error: function 'f' is used but not defined in this translation unit,
and cannot be defined in any other translation unit because its type does not
have linkage
:1:1: used here
f(nullptr)
^
(lldb) p f(&s)
(int) $1 = 0
(lldb) p f(nullptr)
(int) $2 = 1
```

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47528] New: LLDB isn't checking signatures when loading modules from a minidump

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=47528

Bug ID: 47528
   Summary: LLDB isn't checking signatures when loading modules
from a minidump
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: amcca...@google.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

When loading a minidump for post-mortem debugging, LLDB may select the wrong
executable as the target because it checks only file names rather then
signatures, timestamps, etc.  (Also applies to other modules, like DLLs.)

For example, given a minidump from a crashed `C:\Program Files\foo.exe` on a
user's machine, loading that minidump in LLDB in a developer machine might load
a local `foo.exe` simply because it happens to have the same path, even if it
is a different version of the program.

The local one should be rejected based on signature (UUID) and/or other version
information stored in the minidump.  Once rejected, LLDB should continue
searching for a matching binary until it finds one that matches or exhausts all
the locations to be searched.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev