Thanks guys. I tried our IDE against a sample multithreading program on
Mac, it correctly switches selected thread to the worker thread that
triggers breakpoint, while on Linux(CentOS release 6.7) it failed to do
that. Repro code:
*=Output**=*
Launch
Hello all,
I have started using LLDB/MI but there are some commands that are not
working .I start the MI in terminal as "lldb-mi-3.6 --interpreter" and then
launch the application that I want to debug but commands like "n"
,"list","continue" ,"step" are not working.There is this error message tha
All the signals were being used on Windows, but our custom implementation
ignored other signals. I changed it to simply ifdef out the places where we
set other signal handlers. I'd be fine with a higher level mechanism as
well though
On Sun, Mar 20, 2016 at 7:02 AM Pavel Labath wrote:
> Are using
If you send me a small repro case, I can try to look at why is Linux
different here.
On 19 March 2016 at 00:46, Jim Ingham via lldb-dev
wrote:
> All this logic is handled in Process::HandleProcessStateChangedEvent (see
> around line 1215 in Process.cpp) You shouldn’t have to reimplement the log
Are using we using any other signal that SIGINT on windows currently?
I seem to remember all the fancy signals (SIGTSTP, SIGWINCH,...) being
ifdef-ed out on windows. If the only signal we are interested about if
SIGINT, then I think the API should be more higher-level than a
signal() wrapper (SBHos
Hi,
we have been observing that, sporadically, an internal callback set for a
breakpoint is not invoked. We are setting an hidden breakpoint in the
renderscript plugin through:
breakpoint = target.CreateBreakpoint(symbol_address, true, false);
breakpoint->SetCallback(rs_callback, rs_baton, tru
Are you launching the process with -s (stop at entry)?
On Fri, Mar 18, 2016 at 11:24 AM Carlo Kok via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> When starting a process on Win32 there's an internal exception
> (breakpint) that leaks to the debug caller:
> s 'Exception 0x8003 encounter
I'm seeing 2 issues with "target modules load":
Issue #1: load address is forgotten after a connect:
(lldb) file u:\lldb_test\dlopen
Current executable set to 'u:\lldb_test\dlopen' (hexagon).
(lldb) target modules load -f dlopen -s 0x2
(lldb) b main
Breakpoint 1: where = dlope
Make stacks bigger when making threads on linux?
> On Mar 17, 2016, at 1:39 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Seems like the crashes happens because of abi::__cxa_demangle() for mangled
> symbol name "
> _ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8fa
