Re: [lldb-dev] increase timeout for tests?

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

Re: [lldb-dev] increase timeout for tests?

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

Re: [lldb-dev] increase timeout for tests?

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

Re: [lldb-dev] lldb compiled from source 5X slower than homebrew or default lldb

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

[lldb-dev] [Bug 36694] LLDB compile error on s390x

https://bugs.llvm.org/show_bug.cgi?id=36694 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC|

Re: [lldb-dev] increase timeout for tests?

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

Re: [lldb-dev] lldb compiled from source 5X slower than homebrew or default lldb

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:

Re: [lldb-dev] increase timeout for tests?

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

Re: [lldb-dev] increase timeout for tests?

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 >

[lldb-dev] [Bug 36713] New: TestSTL.py fails because "expr associative_array.size()" fails

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:

[lldb-dev] [Bug 36714] New: No support for SBValue::Cast() for C++ types with virtual inheritance

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

[lldb-dev] [Bug 36711] TestMultipleSimultaneousDebuggers fails non-deterministically

https://bugs.llvm.org/show_bug.cgi?id=36711 Vedant Kumar changed: What|Removed |Added Resolution|--- |DUPLICATE

[lldb-dev] [Bug 36712] New: frame var can't access types defined in another shared object from the one holding the current frame

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

[lldb-dev] [Bug 36715] New: Expression evaluation of printf is incorrect (TestPrintf.py)

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:

Re: [lldb-dev] tests xfailed globally with radar references

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 >

Re: [lldb-dev] tests xfailed globally with radar references

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

[lldb-dev] tests xfailed globally with radar references

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

[lldb-dev] settings set target.source-map question

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,

Re: [lldb-dev] increase timeout for tests?

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