[lldb-dev] download page for LLDB at llvm.org

Hi all, I just took a look at our page here: http://lldb.llvm.org/download.html The LLDB Releases section seems pretty out of date. It seems like we could correct that via a few different ways: * Remove the LLDB Releases section - this would eliminate the appearance of us keeping it up to date

Re: [lldb-dev] download page for LLDB at llvm.org

Okay, thanks for weighing in, Mehdi. I'll reach out to the LLVM side and see how they handle the builds, then report back on options there. -Todd On Thu, Nov 10, 2016 at 9:18 AM, Mehdi Amini wrote: > > On Nov 10, 2016, at 9:14 AM, Todd Fiala via lldb-dev < > lldb-dev@list

[lldb-dev] test results look typical?

Hi all, I'm just trying to get a handle on current lldb test failures across different platforms. On Linux on non-virtualized hardware, I currently see the failures below on Ubuntu 14.04.2 using a setup like this: * stock linker (ld.bfd), * g++ 4.9.2 * cmake * ninja * libstdc++ ninja check-lldb

Re: [lldb-dev] test results look typical?

in particular look normal, that'd be good to know. Thanks! > > It's likely that someone could just go in there and remove the XFAIL from > those tests. > > On Mon, Aug 24, 2015 at 3:37 PM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi all,

Re: [lldb-dev] test results look typical?

oose libc++ if it is present? Or do I need to pass something to cmake to use libc++? Thanks, Chaoren! -Todd > On Mon, Aug 24, 2015 at 3:42 PM, Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> >> On Mon, Aug 24, 2015 at 3:39 PM, Zachary Turner >

Re: [lldb-dev] test results look typical?

gt; > > > The TestDataFormatterLibcc* tests require libc++-dev: > > > > $ sudo apt-get install libc++-dev > > > > On Mon, Aug 24, 2015 at 3:42 PM, Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > On Mon, Aug 24, 2015 at 3:39 PM, Za

Re: [lldb-dev] test results look typical?

cmake automatically choose libc++ if it is present? Or do I need to >> pass something to cmake to use libc++? >> >> Thanks, Chaoren! >> >> -Todd >> >> >>> On Mon, Aug 24, 2015 at 3:42 PM, Todd Fiala via lldb-dev < >>> lldb-dev@list

Re: [lldb-dev] test results look typical?

ified that script). -Todd On Mon, Aug 24, 2015 at 6:50 PM, wrote: > On Mon, Aug 24, 2015 at 05:37:43PM -0700, via lldb-dev wrote: > > On Mon, Aug 24, 2015 at 03:37:52PM -0700, Todd Fiala via lldb-dev wrote: > > > On Linux on non-virtualized hardware, I currently see the failures

Re: [lldb-dev] test results look typical?

d success" at the moment is to gather statistics > about them and based on that mark them as "expected flaky" or remove the > "expected failure" based on the number of failures we seen in the last few > hundreds runs. > Ah yes that :-) Love it. Thanks, Ta

Re: [lldb-dev] test results look typical?

h that installed, then ran the tests, and I still have the Libcxc/Libcxx tests failing. Is there some flag expected, either to pass along for the compile options to dotest.py to override/specify which c++ lib it is using? > > Thanks, Chaoren! > > -Todd > > >> On Mon, Aug 24, 20

Re: [lldb-dev] test results look typical?

send the error message > you are getting so we can have a look. > > cheers, > pl > > > On 25 August 2015 at 16:20, Todd Fiala via lldb-dev > wrote: > > > > > > On Mon, Aug 24, 2015 at 4:11 PM, Todd Fiala > wrote: > >> > >

Re: [lldb-dev] test results look typical?

> > >> There is no separate option, it should just work. :) > >> > >> I'm betting you are still missing some package there (we should > >> document the prerequisites better). Could you send the error message > >> you are getting so we can have a lo

Re: [lldb-dev] test results look typical?

gt;> >> >>>> >> There is no separate option, it should just work. :) >>>> >> >>>> >> I'm betting you are still missing some package there (we should >>>> >> document the prerequisites better). Could you

Re: [lldb-dev] test results look typical?

;> >>>>> On 25 August 2015 at 16:45, Todd Fiala wrote: >>>>> > Thanks, Pavel! I'll dig that up and get back. >>>>> > >>>>> > On Tue, Aug 25, 2015 at 8:30 AM, Pavel Labath >>>>> wrote: >

Re: [lldb-dev] test results look typical?

ldb-dev@lists.llvm.org> wrote: > >> There is no separate option, it should just work. :) >> >> I'm betting you are still missing some package there (we should >> document the prerequisites better). Could you send the error message >> you are getting so we

Re: [lldb-dev] test results look typical?

: >>>>> >>>>>> There's no need to do anything fancy (yet :) ). For initial diagnosis >>>>>> the output of `./dotest.py $your_usual_options -p SomeLibcxxTest.py >>>>>> -t` should suffice. >>&g

Re: [lldb-dev] test results look typical?

may dig into that if nobody beats me to it. I did the original multiprocessing work on dosep ~1.5 years ago and it may be doing something goofy. So far the results have been remarkably stable on the counts for me over the last 2 days. > > On Tue, Aug 25, 2015 at 7:41 AM Todd Fiala via lldb-

Re: [lldb-dev] test results look typical?

have never tried that combo but >>>>> I >>>>> don't know that it is impossible. (After all, I just added libc++-dev to >>>>> the system, which presumably I can link against). >>>>> >>>>> On Tue, Aug 25, 2015 at 9:48 AM,

Re: [lldb-dev] test results look typical?

On Tue, Aug 25, 2015 at 4:43 PM, Zachary Turner wrote: > > > On Tue, Aug 25, 2015 at 4:39 PM Todd Fiala wrote: > >> >> Great, thanks Dawn! >> >> I'd like to get all the counts into dosep.py at least as an option, but >> having something to cross check it with is good (and getting a quick answer

Re: [lldb-dev] test results look typical?

gt;>>> /usr/bin/cc -> /etc/alternatives/cc -> /usr/bin/gcc, which would have >>>>>> then caught that it doesn't support libc++. >>>>>> >>>>>> Couldn't we use gcc with libc++? (i.e. is i

Re: [lldb-dev] Test suite rebuilding test executables many times

Not sure if this is relevant, but I seem to recall the remote test execution would spin off each test method run (test case level, not test suite level) into a new directory. I don't think that would be inherently broken by a no-clean scenario but we'd want to make sure it doesn't break. -Todd O

[lldb-dev] test runs: address range spew?

Hi all, When I run tests with dotest.py -v, I'm seeing a lot of tests spew out quite a few lines of output that look like an address with some kind of closed-open range: e.g. 0x002b0eb4: [0x000facc0 - 0x000face4) 0x002b0f24: [0x000facf0 - 0x000fad11) 0x002b0f94: [

Re: [lldb-dev] test runs: address range spew?

// > printf("BuildAddressRangeTable() 0x%8.8x: [0x%16.16" PRIx64 " - > 0x%16.16" PRIx64 ")\n", m_offset, lo_pc, hi_pc); // DEBUG ONLY > > On Wed, Aug 26, 2015 at 2:05 PM, Todd Fiala via lldb-dev > wrote: > > Hi all, > > >

Re: [lldb-dev] test runs: address range spew?

;> /// printf("BuildAddressRangeTable() 0x%8.8x: %30s: [0x%8.8x - >> 0x%8.8x)\n", m_offset, DW_TAG_value_to_name(tag), lo_pc, hi_pc); >> Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp:1897: // >> printf("BuildAddressRangeTable() 0x%8.8x: [0x%16.16" PRIx64

Re: [lldb-dev] test runs: address range spew?

TAG_value_to_name(tag), lo_pc, hi_pc); >>> Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp:1897:// >>> printf("BuildAddressRangeTable() 0x%8.8x: [0x%16.16" PRIx64 " - >>> 0x%16.16" PRIx64 ")\n", m_offset, lo_pc, hi_pc); // DEBU

Re: [lldb-dev] How does attach work on non-Windows?

I seem to recall on the Linux side that this gets a bit complicated. Attaching vs. launching get different sequences of stops, as do the number of hops through possible shells in between a launch and an attach. So we pass through a skip-stop count (which I think both OS X and Linux use) to figure

Re: [lldb-dev] How does attach work on non-Windows?

On Thu, Aug 27, 2015 at 3:01 PM, via lldb-dev wrote: > On Thu, Aug 27, 2015 at 05:05:23PM +, Zachary Turner via lldb-dev > wrote: > > Well I'm xfailing it for now, but this other method seems kind of hackish > > to me because it means the inferior and the debugger have to coordinate > > with

Re: [lldb-dev] Portable tests that create threads

I think the thread naming is a reasonable way to go. > 1) Linux and MacOSX inferiors can use pthread_setname_np > 2) FreeBSD inferiors can use pthread_set_name_np IIRC Linux and FreeBSD both are limited to a very short thread name, much shorter than OS X and, if I'm not mistaken, Windows as well.

Re: [lldb-dev] top-of-tree build failure when using configure on Linux?

I haven't seen that one myself. Are you still seeing it? Is it possible the buildbot's commands are possibly using older/stale object files? Is distcc/ccache involved? Does the build force a clean build? If not, does the issue go away on a clean build? Is it configure-based or cmake based? J

[lldb-dev] Note to buildbot/testbot runners

Hi all, TL;DR: if you call dosep.py directly, you'll need to modify your flow to call dotest.py. *Details:* *dotest.py now runs in parallel test runner mode by default* Starting with lldb svn revision 246794, if you run buildbots or testbots and you directly called dosep.py as a build step, you

Re: [lldb-dev] top-of-tree build failure when using configure on Linux?

o:ztur...@google.com] >> *Sent:* Thursday, September 03, 2015 12:42 PM >> *To:* Todd Fiala; Ted Woodward >> *Cc:* LLDB >> *Subject:* Re: [lldb-dev] top-of-tree build failure when using configure >> on Linux? >> >> >> >> Can you change it to CMake

Re: [lldb-dev] Note to buildbot/testbot runners

A few notes to dotest.py users: * If you want to limit a test run to a test subdirectory *tree*, you can use the new --test-subdir flag. It covers what used to be the supported unnamed argument in dosep.py. It is specified relative to the lldb/test dir. * If you want to use the unnamed argument

[lldb-dev] Windows build questions

Hi all, I've read the Windows lldb build instructions. I have a few questions just to verify before I put too much time into that end: * Has the build been vetted on Windows 10 64-bit yet? * Can Visual Studio 2015 Community Edition work as the compiler toolchain? (VS 2012+ is listed as okay, s

Re: [lldb-dev] Windows build questions

ding on Windows when I finally get > around to it, but it's a lot of work. Still follow the build instructions > anyway because there's other things as well, but the above 3 are probably > the most likely to trip you up. > > On Mon, Sep 7, 2015 at 10:33 AM Todd Fiala via lldb-de

Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

We have a chunk of tests that are marked xfail that pass right now on OS X. I'll go through those in the near future. I'm also seeing several tests consistently unexpectedly pass on Linux x86_64 (Ubuntu 14.04) built with clang-3.6. I think at least some of them fail with gcc-4.9, so they might n

Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

Checking the disposition of these now. On Wed, Sep 9, 2015 at 8:10 AM, Todd Fiala wrote: > We have a chunk of tests that are marked xfail that pass right now on OS > X. I'll go through those in the near future. > > I'm also seeing several tests consistently unexpectedly pass on Linux > x86_64 (

Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

Those radars are both listed as fixed. I'm building and will run the tests on OS X to verify I don't see them here. Assuming they pass, I'll strip the xfail marker. -Todd On Mon, Sep 14, 2015 at 7:32 AM, Todd Fiala wrote: > Checking the disposition of these now. > > On Wed, Sep 9, 2015 at 8:1

Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

I ran the tests against the latest official beta lldb on OS X and they are passing (unexpected successes). Flipping that now... On Mon, Sep 14, 2015 at 7:35 AM, Todd Fiala wrote: > Those radars are both listed as fixed. I'm building and will run the > tests on OS X to verify I don't see them h

Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

Done: Sendingtest/driver/batch_mode/TestBatchMode.py Sendingtest/functionalities/inferior-assert/TestInferiorAssert.py Transmitting file data .. On Mon, Sep 14, 2015 at 7:43 AM, Todd Fiala wrote: > I ran the tests against the latest official beta lldb on OS X and they are > passi

[lldb-dev] cleaning up unexpected successes on OS X

Hey all, As of this change: r247567 | tfiala | 2015-09-14 07:48:53 -0700 (Mon, 14 Sep 2015) | 7 lines I'm seeing the following unexpected successes on OS X: Unexpected Successes (16) UNEXPECTED SUCCESS: LLDB (suite) :: TestCallStdStringFunction.py (Darwin tfiala-mbp-01.local 15.0.0 Darwin Kerne

[lldb-dev] Digging into Linux unexpected successes

On an Ubuntu 14.04 x86_64 system, I'm seeing the following results: *cmake/ninja/clang-3.6:* Testing: 395 test suites, 24 threads 395 out of 395 test suites processed - TestGdbRemoteKill.py Ran 395 test suites (0 failed) (0.00%) Ran 478 test cases (0 failed) (0.00%) Unexpected Successes

[lldb-dev] 7th build slot?

Hi Chaoren, While looking at the Ubuntu 14.04 x86_64 build bot, I was looking at the test configurations for the test slots. 6 of them are described in the build summary on the upper right There is a 7th and 8th test

Re: [lldb-dev] 7th build slot?

Okay, thanks. It would be awesome if the summary listed the specific versions of clang being used. TOT is obvious, but "clang" being 3.5 is less so. Seeing as clang behavior can change between releases, perhaps we can use the other slots for other clang versions? TOT clearly makes sense if more

Re: [lldb-dev] Digging into Linux unexpected successes

rovided. The hole I see right now is we're not adequately dealing with unexpected successes for different configurations. Any reporting around that is helpful. Thanks! > Tamas > > On Mon, Sep 14, 2015 at 11:24 PM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org&g

Re: [lldb-dev] Digging into Linux unexpected successes

l outcome, but it will be a very log list (currently >>> only included for Timeout and Failure) >>> >>> >> I'll know better when I have a look at what you provided. The hole I see >> right now is we're not adequately dealing with unexpected successes

Re: [lldb-dev] Digging into Linux unexpected successes

s for all outcome, but it will be a very log list (currently >>>> only included for Timeout and Failure) >>>> >>>> >>> I'll know better when I have a look at what you provided. The hole I >>> see right now is we're not adequately dealing with

Re: [lldb-dev] Digging into Linux unexpected successes

ession, but they should give you a >>>>>> general idea about what is happening. >>>>>> >>>>>> >>>>> Thanks, Tamas! I'll have a look. >>>>> >>>>> >>>>>> I will try to create

Re: [lldb-dev] Digging into Linux unexpected successes

Yep looks like there's a decent interface to it. Thanks, Siva! I see there's some docs here too: http://docs.buildbot.net/current/index.html On Tue, Sep 15, 2015 at 9:42 AM, Siva Chandra wrote: > On Tue, Sep 15, 2015 at 9:25 AM, Todd Fiala via lldb-dev < > lldb-dev@li

Re: [lldb-dev] Digging into Linux unexpected successes

Change http://reviews.llvm.org/D12831 in review (waiting on Windows results for that) adds a test event stream that supports pluggable test event formatters. The first formatter I've added is JUnit/XUnit output. That's to support typical JUnit/XUnit output handling built into most commercial and

Re: [lldb-dev] 7th build slot?

Thanks for the info, Ying! On Tue, Sep 15, 2015 at 11:04 AM, Ying Chen wrote: > Thanks for the suggestions. > I've changed the descriptions of "clang" to "clang-3.5" since this > > build. > > We currently have 8 test

Re: [lldb-dev] test results look typical?

Great, thanks for filing, Dawn! On Thu, Sep 17, 2015 at 2:08 PM, wrote: > On Mon, Aug 24, 2015 at 05:37:43PM -0700, via lldb-dev wrote: > > On Mon, Aug 24, 2015 at 03:37:52PM -0700, Todd Fiala via lldb-dev wrote: > > > On Linux on non-virtualized hardware, I currently see th

[lldb-dev] changing default test runner from multiprocessing-based to threading-based

Hi all, I'm considering changing the default lldb test runner from multiprocessing-based to threading-based. Long ago I switched it from threading to multiprocessing. The only reason I did this was because OS X was failing to allow more than one exec at a time in the worker threads - way down in

Re: [lldb-dev] [Diffusion] rL248282: test runner: Unix systems now put inferior dotest in its own process group.

Hey Zachary, There is a Windows-specific subprocess.CREATE_NEW_PROCESS_GROUP flag that you could potentially add to the Windows branch of the suprocess creation call in dosep.py. I'm not sure how useful that is on the Windows end as this is mostly about console signal isolation, but I thought I'd

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

e the problem grows to other areas. What other >> things fail horribly when a single instance of LLDB is debugging 100 >> processes at the same time? >> >> It's worth adding this as an alternate run mode, but I don't think we >> should make it default until i

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

oblem grows to other areas. What other >>> things fail horribly when a single instance of LLDB is debugging 100 >>> processes at the same time? >>> >>> It's worth adding this as an alternate run mode, but I don't think we >>> should make it de

Re: [lldb-dev] I see at least one test hanging...

I stopped the two builds in progress (that were badly hanging, 20 minutes per test run configuration) until the builder caught up to r248284. -Todd On Tue, Sep 22, 2015 at 9:06 AM, Todd Fiala wrote: > Rolled back here: > ➜ lldb svn commit > Sendingtest/dosep.py > Transmitting file dat

Re: [lldb-dev] I see at least one test hanging...

I suspect my issue may have been over-isolation. While I only needed a new process group, I did it by creating a new session. The SIGQUIT used by timeout/gtimeout may not be able to work across sessions. I'm going to give this another try with just setting the process group without creating a ne

[lldb-dev] I see at least one test hanging...

Hey all, On the Linux build bot, I'm seeing at least one test hung here after my change: http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/6572 It is conceivable that my change to put the test inferior into a separate process group is interfering with timeout handling. I'll

Re: [lldb-dev] I see at least one test hanging...

Rolled back here: ➜ lldb svn commit Sendingtest/dosep.py Transmitting file data . Committed revision 248284. I'll re-add this and limit to OS X after I get a chance to review. -Todd On Tue, Sep 22, 2015 at 9:01 AM, Todd Fiala wrote: > Hey all, > > On the Linux build bot, I'm seeing a

Re: [lldb-dev] [Diffusion] rL248282: test runner: Unix systems now put inferior dotest in its own process group.

Okay! On Tue, Sep 22, 2015 at 10:14 AM, Zachary Turner wrote: > Thanks for the heads up, I'm familiar with the flag. I'll look into > whether it's appropriate when I get back from CppCon > > On Tue, Sep 22, 2015 at 8:44 AM Todd Fiala wrote: > >> Hey Zachary, >> >> There is a Windows-specific s

[lldb-dev] Ubuntu 15.10 B1 test results

Hi all, FYI - I just gave a build of lldb @248306 on a Ubuntu 15.10 Beta 1 VM running under a VMWare hypervisor. Here's what I saw: LLDB build with clang-3.7 / tests run with inferiors built with gcc 5.2.1 (defaults gcc): Ran 398 test suites (10 failed) (2.512563%) Ran 411 test cases (10 faile

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

n >>>>> even work without dying horribly. In other words, you are inherently >>>>> relying on multiple debuggers working to even run the test suite. >>>>> >>>>> I don't know if that's a problem, but at the very least, it's k

Re: [lldb-dev] I see at least one test hanging...

l 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 hung her

[lldb-dev] Moving test runner timeout logic into Python

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

Re: [lldb-dev] Moving test runner timeout logic into Python

ssume 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 Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi all, >> >&g

Re: [lldb-dev] Moving test runner timeout logic into Python

28 PM, Zachary Turner > wrote: > >> 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 ti

Re: [lldb-dev] Moving test runner timeout logic into Python

t I was thinking. Looked like all of that was >>> available on Windows. We can also have it only optionally time out. >>> >>> Something like that is what I had in mind. >>> >>> On Wed, Sep 23, 2015 at 2:28 PM, Zachary Turner >>>

Re: [lldb-dev] Moving test runner timeout logic into Python

ne way or another. >>>>> >>>>> # do the other post-process activity here... >>>>> >>>>> >>>>> >>>>> ^= that's rough pseudo-code. I need to look up a few details. But >>>>> that's more or less

Re: [lldb-dev] Layout of FXSAVE struct for x86 Architectures in LLDB

I'm using this doc: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf In table 10-2, and again in 13-1, it does appear to call out the most significant byte as reserved (byte 5). As do the instruction details. Looking

Re: [lldb-dev] ThreadPlanStepOverBreakpoint behavior

My suspicion is that the one and only person who knows the answer to that is Jim Ingham, and he won't be available to answer that for roughly another week. On Fri, Sep 25, 2015 at 1:51 PM, Philippe Lavoie via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > I noticed that when a ThreadPlanStepOverB

[lldb-dev] possible test runner speedup

Hi all, I've started looking into test runner speeds based on the number of threads. Since we first introduced the parallel test runner, we've defaulted to using a number of work queues equal to the number of logical processors reported by the machine. Thus on a 24 core Linux box (12 hyperthread

Re: [lldb-dev] possible test runner speedup

On Mon, Sep 28, 2015 at 2:12 AM, Pavel Labath wrote: > Hi, > > Interesting results. We were discussing the same thing last week. I > was somewhat skeptical to the ideal as I am afraid of increased > flakyness -- LLDB has hardcoded timeout values in a lot of places, and > with increased cpu conten

[lldb-dev] TestAttachDenied - timing out

Hi all, I've been running the test suite for quite some time on the Linux side. I pretty consistently see this test case file: TestAttachDenied.py time out on my Linux setup (prior to any of my test runner changes). I'm noticing it is now showing up on the Google Linux buildbot (here - build 6

Re: [lldb-dev] TestAttachDenied - timing out

That said, I'm going to disable the test and look into why it is timing out so our poor Google test runner doesn't take forever to go through the tests. I'll file a ticket and look into it. On Tue, Sep 29, 2015 at 3:54 PM, Todd Fiala wrote: > Hi all, > > I've been running the test suite for qui

Re: [lldb-dev] TestAttachDenied - timing out

I disabled it on Linux with this: svn commit Sending functionalities/process_attach/attach_denied/TestAttachDenied.py Transmitting file data . Committed revision 248846. On Tue, Sep 29, 2015 at 4:02 PM, Todd Fiala wrote: > That said, I'm going to disable the test and look into why it is timin

Re: [lldb-dev] TestAttachDenied - timing out

I killed build 6803 on the Linux buildbot since the tests would have taken 25+ minutes to run through the timeout on the theory that getting the results net faster would be better. 6804+ should have the test disabled that was timing out. On Tue, Sep 29, 2015 at 4:09 PM, Todd Fiala wrote: > I di

Re: [lldb-dev] Too many open files

(swapped out the lldb list for the newer one) On Fri, Oct 2, 2015 at 5:37 PM, Todd Fiala wrote: > Hmm, sounds suspicious. > > Can you try running the tests with two options and see if you get > different results? > > # should be equivalent for the default on Windows, thus should match your > abo

Re: [lldb-dev] Can't debug with a -g compiled binary as a non-root user on OS X 10.11 El Capitan

Hi Tony, This is the right list. Are you using an LLDB that you built locally? If so, can you move aside the debugserver that you find somewhere under in your LLDB.framework bundle directory, and make a symlink to the debugserver that comes out of your /Applications/Xcode.app bundle? Your offic

Re: [lldb-dev] TestAttachDenied - timing out

this data on python side. > > > On Tue, Sep 29, 2015 at 4:17 PM, Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> I killed build 6803 on the Linux buildbot since the tests would have >> taken 25+ minutes to run through the timeout on the theory that ge

Re: [lldb-dev] Too many open files

Interesting, okay.. This does appear to be an accumulation issue. You made it most of the way through before the issue hit. I suspect we're leaking file handles. It probably doesn't hit the per-process limit on multiprocessing because the leaked files get spread across more processes. (All spe

Re: [lldb-dev] Too many open files

Hmm, on OS X the file handles seem to be well behaved on the --test-runner-name threading. I'm not seeing any file handle growth beyond the file handles I expect to be open. I'll see if the threading-pool behaves differently. (That is similar to threading but uses the multiprocessing.pool mechan

Re: [lldb-dev] Too many open files

On OS X, I'm also not seeing growth in the --test-runner-name threading-pool (the one you were using on Windows). Perhaps you can dig into if you're experiencing some kind of file leak on Windows. It's possible you're hitting a platform-specific leak? I recall Ed Maste hitting a FreeBSD-only lea

Re: [lldb-dev] Too many open files

It's possible. However, I was monitoring actual open files during the course of the run (i.e. what the kernel thought was open for the master driver process, which is the only place that makes sense to see leaks accumulate) in both threading and threading-pool (on OS X), and I saw only the handful

Re: [lldb-dev] Testing through api vs. commands

IMHO that all sounds reasonable. FWIW - I wrote some tests for the test system changes I put in (for the pure-python impl of timeout support), and in the process, I discovered a race condition in using a python facility that there really is no way I would have found anywhere near as reasonably wit

Re: [lldb-dev] Testing through api vs. commands

> I didn't follow those threads, can you summarize what the race condition was? Is it likely to crop up in the normal test suite? i.e. not the test suite that tests the test suite. Sure. At least on OS X and Linux, the impl of subprocess.Popen.wait() and subprocess.Popen.poll() are written such

Re: [lldb-dev] Preliminary support for NetBSD

Seems like a great idea. (Ed, is that something you might be able to review?) Hopefully you have access to other platforms to test if it's breaking anything? (Most likely candidates would be FreeBSD and Linux/Android, I'd suspect, depending on how much you're having to change things). On Wed, S

Re: [lldb-dev] Too many open files

On Mon, Oct 5, 2015 at 3:58 PM, Adrian McCarthy wrote: > Different tools are giving me different numbers. > > At the time of the error, Windbg says there are about 2000 open handles, > most of them are Event handles, not File handles. That's higher than I'd > expect, but not really concerning. >

Re: [lldb-dev] Too many open files

Okay. A promising avenue might be to look at how Windows cleans up the threading.Event objects. Chasing that thread might yield why the events are not going away (assuming those are the events that are lingering on your end). One thing you could consider doing is patching in a replacement destru

Re: [lldb-dev] Testing through api vs. commands

Hey Zachary, > What are the chances of someone attempting to get the existing unit test runner working in the Xcode build? Or at least attempting to and seeing if there's any major blockers that prevent it from working? I fully intend to do that. I need to do a few more pieces of infrastructura

Re: [lldb-dev] Too many open files

Oh good! I'm glad you found the root cause. Later I anticipate the following will happen, which may help: * the test event system is arranged to capture stdout/stderr from each test method within the test events. * the stdout/stderr from the inferior dotest.py will become far less important and t

Re: [lldb-dev] How to debug LLDB server?

On Wed, Oct 7, 2015 at 8:03 PM, Bruce Mitchener via lldb-dev < lldb-dev@lists.llvm.org> wrote: > In the LLDB project, you have 3 different defines: > > LLDB_CONFIGURATION_DEBUG > LLDB_CONFIGURATION_RELEASE > LLDB_CONFIGURATION_BUILD_AND_INTEGRATION > > I can easily set this up to be set for the va

Re: [lldb-dev] Python 3 and dotest

On Mon, Oct 12, 2015 at 7:31 PM, Zachary Turner wrote: > Moving this to the public list because it seems useful to see what other > members of the community have to say as well. > > On Mon, Oct 12, 2015 at 4:22 PM Zachary Turner wrote: > >> It's worth also pointing out that if we go the route of

Re: [lldb-dev] Python 3 and dotest

On Tue, Oct 13, 2015 at 9:45 AM, Zachary Turner wrote: > On Mon, Oct 12, 2015 at 7:31 PM Zachary Turner wrote: > >> Moving this to the public list because it seems useful to see what other >> members of the community have to say as well. >> > > BTW , I realized I didn't give any context here and

Re: [lldb-dev] incorrect shared library addresses

> Breakpoint 1: where = wikilinktester`main.main + 805 at wikilinktester.go:35, address = 0x2365 The address of the breakpoint is kinda interesting - that seems suspiciously low for an OS X user executable. Which lldb are you using? If you built it, what process did you use to build

[lldb-dev] Question on assert

Hi Tamas, There is an assert in DWARFDIE.cpp (lines 189 - 191) that we're hitting on the OS X side somewhat frequently nowadays: assert ((id&0xull) == 0 || (cu_id&0xll) == 0 || (id&0xull) == (cu_

Re: [lldb-dev] Question on assert

Okay! I'll give that a shot now and report back what I find. Thanks, Tamas :-) -Todd On Thu, Oct 15, 2015 at 3:37 AM, Tamas Berghammer wrote: > Hi Todd, > > The 64 bit ID of a DIE is built up in the following way: > * The offset of the DIE is in the lower 32 bit > * If we are using SymbolFile

Re: [lldb-dev] Question on assert

I'm re-running the tests to make sure, but I think that fixed it. I had always seen it at least once on test runs locally, but didn't see it on the last one. On Thu, Oct 15, 2015 at 8:10 AM, Todd Fiala wrote: > Okay! I'll give that a shot now and report back what I find. > > Thanks, Tamas :-)

Re: [lldb-dev] Question on assert

This seems to be working. I put it up for review here, Tamas: http://reviews.llvm.org/D13777 On Thu, Oct 15, 2015 at 9:03 AM, Todd Fiala wrote: > I'm re-running the tests to make sure, but I think that fixed it. I had > always seen it at least once on test runs locally, but didn't see it on t

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

On Thu, Oct 15, 2015 at 8:50 AM, Adrian McCarthy via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I've tracked down a source of flakiness in tests on Windows to Python > object lifetimes and the SB interface, and I'm wondering how best to handle > it. > > Consider this portion of a test from TestT

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

On Thu, Oct 15, 2015 at 9:23 AM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > That wouldn't work in this case because it causes a failure from one test > to the next. So a single test suite has 5 tests, and the second one fails > because the first one didn't clean up correctly.

<    1   2   3   4   >