On Wed, Sep 23, 2015 at 11:44:41AM -0700, Greg Clayton wrote:
> We currently coalesce breakpoints to avoid the user stopping multiple times
> on the same source line. This might have been done to avoid stepping issues
> we might have had in the past, but we have made many modifications to
> step
https://llvm.org/bugs/show_bug.cgi?id=24812
Siva Chandra changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Cool. Win win :-)
On Wed, Sep 23, 2015 at 2:57 PM, Zachary Turner wrote:
> We definitely want timeouts. I was planning to implement timeout /
> gtimeout in C++ and checking it in and building it as part of the build
> process. But this would be better for obvious reasons.
>
> On Wed, Sep 23,
We definitely want timeouts. I was planning to implement timeout /
gtimeout in C++ and checking it in and building it as part of the build
process. But this would be better for obvious reasons.
On Wed, Sep 23, 2015 at 2:56 PM Todd Fiala wrote:
> Yeah good idea.
>
> Anyways, that's what I'm goi
Yeah good idea.
Anyways, that's what I'm going after.
On the Windows front, is there any reason other than lack of
timeout/gtimeout why you wouldn't want timeouts? I'm trying to figure if
there is any reason I would want to work this in as an optional thing.
(Making it not optional would be sli
No obvious reason I see why that wouldn't work. You probably want to wrap
the "thread 1" code in a try: ... except: pass because p.terminate probably
will cause an exception on the other thread.
On Wed, Sep 23, 2015 at 2:40 PM Todd Fiala wrote:
> A nice bit here, also, is for those places where
A nice bit here, also, is for those places where we are using timeout
(Linux, OS X, etc.) we get to trade off and use a thread where we were
using a whole different process. (i.e. the timeout wrapper process goes
away).
On Wed, Sep 23, 2015 at 2:38 PM, Todd Fiala wrote:
> Yep - the approach (fo
Yep - the approach (for now) is likely to look like:
p = subprocess.Popen(...) # exact call differs between Windows/Non-Windows
done_event = # some kind of semaphore/event, probably
threading.Thread.Event()
spinup thread 1, running this code:
# Thread 1 - grab output, do communicate() call
Can you offer a hint about how you plan to implement this? When you say it
we should get the same behavior everywhere, I assume this means Windows
too, which currently does not support running with a timeout at all
(because timeout / gtimeout aren't present)
On Wed, Sep 23, 2015 at 2:22 PM Todd F
Hi all,
Over the last two days, I've hit some inconsistencies across platforms
surrounding signal handling and the operation of the timeout/gtimeout
executable mechanism that we use to handle timeouts of tests. The net
result is I still see tests sometimes hang up the test running process,
even t
We currently coalesce breakpoints to avoid the user stopping multiple times on
the same source line. This might have been done to avoid stepping issues we
might have had in the past, but we have made many modifications to stepping
such that the step thread plans now know how to step through two
https://llvm.org/bugs/show_bug.cgi?id=24916
Bug ID: 24916
Summary: Expression evaluation: out-of-line definition of
'$__lldb_expr' does not match any declaration in 'Foo'
Product: lldb
Version: unspecified
Hardware: PC
Maybe - can you get me access to a setup that exhibits this and I'll poke
around? Also, is the line in the bug exactly what needs to be run to
reproduce?
Thanks!
On Wed, Sep 23, 2015 at 12:43 AM, Sylvestre Ledru
wrote:
> I am experiencing a similar issue with the 3.7 branch on all Ubuntu
> ver
https://llvm.org/bugs/show_bug.cgi?id=24915
ema...@freebsd.org changed:
What|Removed |Added
Component|All Bugs|new bugs
Version|unspecified
https://llvm.org/bugs/show_bug.cgi?id=24912
Todd Fiala changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://llvm.org/bugs/show_bug.cgi?id=24915
Bug ID: 24915
Summary: Unsupported immediate operand assembler branch
mnemonics
Product: lldb
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
I am experiencing a similar issue with the 3.7 branch on all Ubuntu version:
https://llvm.org/bugs/show_bug.cgi?id=24912
Debian works fine.
Does it ring a bell?
Sylvestre
Le 22/09/2015 18:01, Todd Fiala via lldb-dev a écrit :
> Hey all,
>
> On the Linux build bot, I'm seeing at least one test hun
https://llvm.org/bugs/show_bug.cgi?id=24912
Bug ID: 24912
Summary: lldb-test-traces freeze on all Ubuntu
Product: lldb
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
18 matches
Mail list logo
