Re: [lldb-dev] Race condition crashes during launching LLDB

After adding some logging I figured out that the race condition is caused by process.Continue() did not guarantee process has been really resumed yet in async mode, so the second wait_for_process_stop() is skipped immediately to kill listener thread and destroying debugger. I know I have a race con

Re: [lldb-dev] Race condition crashes during launching LLDB

I don't know what: event_thread = LLDBListenerThread(debugger) does, but from your little sketch it looks like you are starting up a thread listening on this debugger, and so far as I can see you destroy the debugger out from under it without ever closing down that thread. That doesn't see

[lldb-dev] Race condition crashes during launching LLDB

Hi, I am revising our lldb automation tests into async mode. However, I found it randomly crashes depends on timing. And the crash happens mostly while launching lldb twice in a row. I have narrowed down the code into a simple repro below. Any assumption I made wrong with the LLDB API here? The c

Re: [lldb-dev] Debug events in synchronous mode?

Jim, thanks for the confirmation. It seems to me that there are many quirks of LLDB API that you have to be aware of before you can automate it correctly. Are these quirks documented somewhere that I missed? I have looked at examples/tests folders of LLDB and python API pages, both do not have enou

[lldb-dev] Minidump support in LLDB

Below is an after-the-fact design doc on the minidump support in LLDB. We don't seem to have a documents repository, so I thought I'd post it here on the mailing list in case anyone wants to know more. Comments and questions welcome. Thanks, Adrian. --- Minidump support in LLDB Adrian McCarthy

[lldb-dev] lldb-mi and shared library path

I'd expect "-gdb-set solib-search-path" to call "target modules search-paths add", and it does, but only when the -target-remote command is issued. It also doesn't handle the multiple path case, :. I think it should: 1) Set the search path immediately when called, if the target is conn

Re: [lldb-dev] Inquiry for performance monitors

> On Feb 4, 2016, at 2:24 AM, Pavel Labath via lldb-dev > wrote: > > On 4 February 2016 at 10:04, Ravitheja Addepally > wrote: >> Hello Pavel, >>In the case of expression evaluation approach you mentioned >> that: >> 1. The data could be accessible only when the target is stopp

Re: [lldb-dev] [cfe-dev] [3.8 Release] RC2 has been tagged

Tested RC2 w/SLES11.3, x86_64. No regressions. 81c1ea3fafee883fbbd396779d1e62714304eff6 rc2/clang+llvm-3.8.0-rc2-linux-x86_64-sles11.3.tar.xz On Tue, Feb 2, 2016 at 3:15 PM, Hans Wennborg via cfe-dev < cfe-...@lists.llvm.org> wrote: > Dear testers, > > Release Candidate 2 has just been tagged

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

We can change to 3+2015; if you guys don't think 2+2013 is useful, we'll do that. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -Original Message- From: Pavel Labath [mailto:lab...@goog

Re: [lldb-dev] Debug events in synchronous mode?

In synchronous mode, you should never see events. The part of lldb that is making the command synchronous is using those events to make the command wait till the action it initiated completes before it returns. If it is letting process control events leak out, then that is a bug. If you are r

Re: [lldb-dev] [Release-testers] [3.8 Release] RC2 has been tagged

On 04 Feb 2016, at 09:09, Dimitry Andric via Release-testers wrote: > > On 02 Feb 2016, at 22:15, Hans Wennborg via Release-testers > wrote: >> >> Release Candidate 2 has just been tagged [1]. Please build, test, and >> upload to the sftp. >> >> I know there are still outstanding issues from

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

The patch is in the attachment. The timezone part seems pretty non-controversial. The _PyVerify_fd thing seems more scary, but I basically copied that part out of python3, so I assume they know what they are doing. With this I can compile and run the python and it appears to be working. The real t

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

Out of curiosity, did you guys get Python 2.7 building with VS2015? How did you solve the compiler error? (I had a few ideas myself for how to fix it, but I wasn't sure of the implications) On Thu, Feb 4, 2016 at 8:01 AM Pavel Labath wrote: > Hi all. > > we (android lldb team) are starting to

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

Hi all. we (android lldb team) are starting to transition to VS2015 as well. For now, the plan is to stick to python 2.7, but if we encounter problems there, the backup plan is to go to python 3 as well. Until then (I estimate that will take 1--2 weeks) our buildbot

[lldb-dev] FOSDEM slides online

Hi folks, FOSDEM was a great success, with the room packed most of the time and some great talks. The slides were uploaded to the web page (http://llvm.org/devmtg/2016-01/) but the videos unfortunately couldn't be used (they had no audio). Due to the voluntary nature of FOSDEM, these things can a

Re: [lldb-dev] Inquiry for performance monitors

On 4 February 2016 at 12:49, Abhishek Aggarwal wrote: > Hello Pavel > > As per my understanding, instead of doing it by expression evaluation > if the code (to enable pt and gathering the raw traces) is written on > lldb-server side, then also lldb-server will have to wait for the > inferior to st

Re: [lldb-dev] Inquiry for performance monitors

Hello Pavel As per my understanding, instead of doing it by expression evaluation if the code (to enable pt and gathering the raw traces) is written on lldb-server side, then also lldb-server will have to wait for the inferior to stop in order to encapsulate all the traces in packets and send them

Re: [lldb-dev] Inquiry for performance monitors

Yes, thanx for the clarification. On Thu, Feb 4, 2016 at 11:24 AM, Pavel Labath wrote: > On 4 February 2016 at 10:04, Ravitheja Addepally > wrote: > > Hello Pavel, > > In the case of expression evaluation approach you > mentioned > > that: > > 1. The data could be accessible onl

Re: [lldb-dev] Problem running the test suite on Linux.

In addition to flaky tests, I think some of these are just decorated too broadly (e.g. it's marked expectedFailureLinux, but fails only on i386 with gcc). I occasionally enable tests that I see are passing consistently, but I am currently more worried about tests failing unexpectedly than succeedin

Re: [lldb-dev] Inquiry for performance monitors

On 4 February 2016 at 10:04, Ravitheja Addepally wrote: > Hello Pavel, > In the case of expression evaluation approach you mentioned > that: > 1. The data could be accessible only when the target is stopped. why is that > ? If I understand the approach correctly, the idea is the ru

Re: [lldb-dev] Inquiry for performance monitors

Hello Pavel, In the case of expression evaluation approach you mentioned that: 1. The data could be accessible only when the target is stopped. why is that ? 2. What sort of noise were you referring to ? BR, A Ravi Theja On Mon, Feb 1, 2016 at 1:05 PM, Tamas Berghammer wrote:

Re: [lldb-dev] Debug events in synchronous mode?

Hi, I am not sure what are the "official" rules, but the general idea is that you need not concern yourself too much with events when you are in synchronous mode. In synchronous mode, you can be sure that by the time target.Launch() returns, the process will be stopped (or dead, or something else,

Re: [lldb-dev] Sending input to the process being debugged

Hi, I think you will have to provide a bit more context to get help. I.e., what is the full sequence of debugger commands you are issuing, and what is the inferior process doing? cheers, pl On 3 February 2016 at 22:03, John Lindal via lldb-dev wrote: > When I use SBDebugger::SetAsync(true), the

Re: [lldb-dev] [Release-testers] [3.8 Release] RC2 has been tagged

On 02 Feb 2016, at 22:15, Hans Wennborg via Release-testers wrote: > > Release Candidate 2 has just been tagged [1]. Please build, test, and > upload to the sftp. > > I know there are still outstanding issues from RC1, but there have > been a lot of merges going into the branch and I think it's