When using "settings set target.source-map", when we try to set breakpoints by
file and line, we try to undo any source remapping we did so we can set the
breakpoint correctly:
BreakpointSP Target::CreateBreakpoint(const FileSpecList *containingModules,
cons
It is unfortunate that we have to set really long test timeouts because we are
timing the total Test class run, not the individual tests. It is really
convenient to be able to group similar tests in one class, so they can reuse
setup and common check methods etc. But if we're going to have to
As a first step, I think there's consensus on increasing the test timeout to
~3x the length of the slowest test we know of. That test appears to be
TestDataFormatterObjC, which takes 388 seconds on Davide's machine. So I
propose 20 minutes as the timeout value.
Separately, regarding x-failed pe
I took a first cut at this in r327463.
vedant
> On Mar 13, 2018, at 2:39 PM, Vedant Kumar wrote:
>
> Hi Ted,
>
> Thanks for bringing this up. I'll volunteer to take a look at these tests and
> file PRs where appropriate. I should get to this within a day or two.
>
> vedant
>
>> On Mar 13, 2
https://bugs.llvm.org/show_bug.cgi?id=36715
Bug ID: 36715
Summary: Expression evaluation of printf is incorrect
(TestPrintf.py)
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
https://bugs.llvm.org/show_bug.cgi?id=36714
Bug ID: 36714
Summary: No support for SBValue::Cast() for C++ types with
virtual inheritance
Product: lldb
Version: unspecified
Hardware: PC
OS: All
St
https://bugs.llvm.org/show_bug.cgi?id=36713
Bug ID: 36713
Summary: TestSTL.py fails because "expr
associative_array.size()" fails
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: N
https://bugs.llvm.org/show_bug.cgi?id=36712
Bug ID: 36712
Summary: frame var can't access types defined in another shared
object from the one holding the current frame
Product: lldb
Version: unspecified
Hardware: PC
https://bugs.llvm.org/show_bug.cgi?id=36711
Vedant Kumar changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bugs.llvm.org/show_bug.cgi?id=36711
Bug ID: 36711
Summary: TestMultipleSimultaneousDebuggers fails
non-deterministically
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NE
https://bugs.llvm.org/show_bug.cgi?id=36710
Bug ID: 36710
Summary: AsanTestReportDataCase unsupported on i386
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Hi Ted,
Thanks for bringing this up. I'll volunteer to take a look at these tests and
file PRs where appropriate. I should get to this within a day or two.
vedant
> On Mar 13, 2018, at 10:31 AM, Ted Woodward via lldb-dev
> wrote:
>
> I was investigating TestWatchedVarHitWhenInScope.py, whic
On Tue, Mar 13, 2018 at 11:26 AM, Jim Ingham wrote:
> It sounds like we timing out based on the whole test class, not the
> individual tests? If you're worried about test failures not hanging up the
> test suite the you really want to do the latter.
>
> These are all tests that contain 5 or mor
It sounds like we timing out based on the whole test class, not the individual
tests? If you're worried about test failures not hanging up the test suite the
you really want to do the latter.
These are all tests that contain 5 or more independent tests. That's probably
why they are taking so
Few examples:
360 out of 617 test suites processed - TestObjCMethods.py
XX
TestObjCMethods.py: 363.726592
381 out of 617 test suites processed - TestHiddenIvars.py
XX
TestHiddenIvars.py: 363.887766
387 out of 61
I was investigating TestWatchedVarHitWhenInScope.py, which tests that a
watchpoint is hit in scope and not hit when out of scope. It's xfailed due
to a radar:
@unittest2.expectedFailure("rdar://problem/18685649")
This is an actual bug - watchpoints are hit when the address is modified but
the
I'll re-run the test and send you a list.
Thank you!
--
Davide
On Tue, Mar 13, 2018 at 9:02 AM, Pavel Labath wrote:
> Aha, in that case, it definitely sounds like increasing the timeout is in
> order. I would still go for something less than 30 minutes, but I don't care
> about that much. I may
Aha, in that case, it definitely sounds like increasing the timeout is in
order. I would still go for something less than 30 minutes, but I don't
care about that much. I may just export LLDB_TEST_TIMEOUT locally to lower
it if tests taking long to time out start bugging me.
BTW, do you know which
Good catch Pavel, I missed that part where it calls Index manually even if we
have accelerator tables where we don't need to manually index.
We should modify SymbolFileDWARF::Index() that currently looks like:
void SymbolFileDWARF::Index() {
if (m_indexed)
return;
...
}
To look like:
On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath wrote:
> I think we should get some data before pulling numbers out of our sleeves.
> If we can get some numbers on the slowest machine that we have around, then
> we should be able to specify the timeout as some multiple of the slowest
> test. For exa
I think we should get some data before pulling numbers out of our sleeves.
If we can get some numbers on the slowest machine that we have around, then
we should be able to specify the timeout as some multiple of the slowest
test. For example, for me the slowest test takes around 110 seconds. The
ti
I would start by looking at https://reviews.llvm.org/D32598, which adds a
bunch of work we do up-front. I remember looking at this a while back and
not being sure whether all of that work is relevant for osx, actually. (I'm
specifically thinking of the SymbolFileDWARF::Index call, which is done
unc
https://bugs.llvm.org/show_bug.cgi?id=36694
lab...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
23 matches
Mail list logo
