Hello,
I'm facing the following 6.0.0-rc1 crash on Linux/X86:
#0 0x70e027b6 in std::__uniq_ptr_impl >::_M_ptr (this=0x28)
at /usr/include/c++/7/bits/unique_ptr.h:147
#1 0x70e01cbe in std::unique_ptr >::get (this=0x28) at
/usr/include/c++/7/bits/unique_ptr.h:337
#2 0x7
I'm trying to setup a pending breakpoint for sin() and cos() which are
dlsym()ed from libm.so
(sample attached), and an attempt to continue execution seems just hangs the
debugger. For example:
(lldb) attach 17043
Process 17043 stopped
* thread #1, name = 't-dlopen', stop reason = signal SIGSTO
On 02/15/2018 02:21 PM, Pavel Labath wrote:
I've tried your sample, and I was indeed able to reproduce the
problem. What makes your case special is that "sin" and "cos" are
indirect functions (STT_GNU_IFUNC), so we have to do some extra work
(call the resolver function) to resolve them.
I've
While operating on a breakpoints, is it correct to use 'breakpoint delete'
without
previous 'breakpoint disable'? With this scenario, I'm observing 6.0.0-rc2
crash with:
$ /home/dantipov/.local/llvm-6.0.0/bin/lldb t-thread2
(lldb) target create "t-thread2"
Current executable set to 't-thread2'
On 02/28/2018 11:31 AM, jonas echterhoff via lldb-dev wrote:
I'm using lldb-900.0.64.
^^
??
Latest official release is 5.0.1; also there are 6.0.0 (at -rc3, the next
release)
and 7.0.0 (a.k.a SVN trunk). What's the 'version' output of your LLDB p
Does anyone has an explanation of this weird run of 'valgrind --tool=drd':
==2715== drd, a thread error detector
==2715== Copyright (C) 2006-2017, and GNU GPL'd, by Bart Van Assche.
==2715== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==2715== Command: /home/antipov/.local/
On 9/24/20 9:14 PM, Greg Clayton wrote:
This must be a valgrind issue, there would be major problems if the OS isn't able to lock
mutex objects correctly ("mutex is locked simultaneously by two threads"). It
is getting confused by a recursive mutex? LLDB uses recursive mutexes.W
LLDB's Predi
On 9/25/20 5:53 PM, Dmitry Antipov wrote:
On 9/24/20 9:14 PM, Greg Clayton wrote:
This must be a valgrind issue, there would be major problems if the OS isn't able to lock mutex objects correctly ("mutex is locked simultaneously by two threads"). It is getting confused by a
recursive mutex? LL
On 9/29/20 11:40 PM, Greg Clayton wrote:
How could LLDB even function then? We are using the standard std::mutex +
std::condition workflow here. Not sure how LLDB could even function if it
locking was nor working as expected.
Well, obviously this is an issue (and probably the same one) with
I'm observing the following deadlock:
One thread calls Module::PreloadSymbols() which takes m_mutex of this Module.
Module::PreloadSymbols()
calls ManualDWARFIndex::Index(), which, in turn, creates thread pool and waits
for all threads completion:
(gdb)
#0 futex_wait_cancelable (private=0, ex
10 matches
Mail list logo
