Author: aleksandr.urakov
Date: Fri Aug 17 00:28:24 2018
New Revision: 339994
URL: http://llvm.org/viewvc/llvm-project?rev=339994&view=rev
Log:
Fix compiler warnings after rL339649.
Differential Revision: https://reviews.llvm.org/D49980
Modified:
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBAS
aleksandr.urakov added a comment.
Thanks for catching that!
I didn't know about that warnings because I build LLVM with MSVC compiler, but
it doesn't introduce such warnings. Now I've fixed the problem with
https://reviews.llvm.org/rLLDB339994.
Repository:
rL LLVM
https://reviews.llvm.org/
Author: gclayton
Date: Fri Aug 17 10:27:53 2018
New Revision: 340050
URL: http://llvm.org/viewvc/llvm-project?rev=340050&view=rev
Log:
Change the attach test case to use self.assertEqual so we can get more info on
what is going wrong on test bots.
Also add a cleanup function to remove the copied
After reading through the code in TestVSCode_attach.py I see that there are
lots of commands with a 1s timeout. I would not be surprised if that is too
small for running on a bot, which is by definition under extreme load. Do you
think increasing the timeouts would help?
-- adrian
_
It it failing to set a breakpoint in a binary before we even run. If we run
into other errors then increasing the timeout would make sense. But here it is
setting a source regex breakpoint on "// breakpoint 1" and it isn't getting the
number of locations. I just committed 340050 which uses a sel
I can expectedFail this test if needed?
> On Aug 17, 2018, at 10:34 AM, Greg Clayton wrote:
>
> It it failing to set a breakpoint in a binary before we even run. If we run
> into other errors then increasing the timeout would make sense. But here it
> is setting a source regex breakpoint on "/
Author: jingham
Date: Fri Aug 17 10:39:32 2018
New Revision: 340053
URL: http://llvm.org/viewvc/llvm-project?rev=340053&view=rev
Log:
Show how to use "lldb -P" to find the lldb.py.
We had hard-coded the path in the docs but that got
out of date - showing again that -P is the better
way to do this.
teemperor created this revision.
teemperor added a reviewer: jingham.
Herald added a subscriber: abidh.
https://reviews.llvm.org/D48465 is currently blocked by the fact that
tab-completing the first expression is deadlocking LLDB.
The reason for this deadlock is that when we push the ProcessIO h
> On Aug 17, 2018, at 10:35 AM, Greg Clayton wrote:
>
> I can expectedFail this test if needed?
I'm afraid it looks like that won't be good enough. I just had to manually log
into the build node and kill TestVSCode_variables.py, too, because it was
hanging indefinitely. We either need to fig
Here's the output from attach:
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/9017/testReport/lldb-Suite/tools_lldb-vscode_attach/TestVSCode_attach_py
> On Aug 17, 2018, at 11:32 AM, Adrian Prantl via lldb-commits
> wrote:
>
>
>
>> On Aug 17, 2018, at 10:35 AM, Greg Clayton wrote:
jingham added a comment.
It isn't true that the ProcessIO handler will have a short duration, in
general. It will live on the stack as long as process is running, which is of
arbitrary duration. I actually don't think that much matters to this
discussion, however.
The most common IOHandler
Here's a third failure:
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/9021/console
==
FAIL: test_commands (TestVSCode_launch.TestVSCode_launch)
--
Tra
Author: gclayton
Date: Fri Aug 17 13:42:06 2018
New Revision: 340077
URL: http://llvm.org/viewvc/llvm-project?rev=340077&view=rev
Log:
Skip the lldb-vscode attach with waitFor test for now, some build bots are
having trouble.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-v
I run everything on a mac and there are no failures on my machine.
Can you find out exactly how the test suite is invoked so I can try to
reproduce?
> On Aug 17, 2018, at 1:39 PM, Adrian Prantl wrote:
>
> Here's a third failure:
>
> http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/90
On Aug 17, 2018, at 1:44 PM, Greg Clayton wrote:
> I run everything on a mac and there are no failures on my machine.
> Can you find out exactly how the test suite is invoked so I can try to
> reproduce?
You can find the exact invocation in the build logs:
cmake /Users/buildslave/jenkins/wor
> On Aug 17, 2018, at 1:49 PM, Adrian Prantl wrote:
>
>
> On Aug 17, 2018, at 1:44 PM, Greg Clayton wrote:
>
>> I run everything on a mac and there are no failures on my machine.
>> Can you find out exactly how the test suite is invoked so I can try to
>> reproduce?
>
> You can find the e
We really need to do *something*. Normally our lldb-cmake bot churns out a
fresh run every 10 minutes, now it is timing out after 1.5 hours:
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/9021/consoleFull#console-section-10
Build timed out (after 90 minutes). Marking the build as aborte
vsk added inline comments.
Comment at: source/Plugins/Language/CPlusPlus/LibCxx.cpp:46
+ // Member __f_ has type __base*, the contents of which will either directly
+ // hold a pointer to the callable object or vtable entry which will hold the
+ // type information need to dis
Author: gclayton
Date: Fri Aug 17 17:33:15 2018
New Revision: 340112
URL: http://llvm.org/viewvc/llvm-project?rev=340112&view=rev
Log:
Skip tests on Darwin for now. The build bots are not passing due to heavy load
and poor machines.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/
$ svn commit
Sending
packages/Python/lldbsuite/test/tools/lldb-vscode/attach/TestVSCode_attach.py
Sending
packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
Sending
packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_s
Thanks! Do let me know if I can help you with figuring this out.
-- adrian
> On Aug 17, 2018, at 5:34 PM, Greg Clayton wrote:
>
> $ svn commit
> Sending
> packages/Python/lldbsuite/test/tools/lldb-vscode/attach/TestVSCode_attach.py
> Sending
> packages/Python/lldbsuite/test/tool
21 matches
Mail list logo