[lldb-dev] test decorator working on linux, but not on windows

2017-01-06 Thread Ted Woodward via lldb-dev 
packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py has this
decorator:

 

@expectedFailureAll(compiler="clang", bugnumber="llvm.org/pr19238")

 

On Linux, I'm building with hexagon-clang, and this decorator fires, so the
test is xfailed.

On Windows, I'm building with hexagon-clang.exe, and this decorator is
evidently not firing, because the test fails instead of being xfailed.

 

Linux is using Python 2.7.8. Windows is using Python 3.5.1.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] test decorator working on linux, but not on windows

2017-01-06 Thread Zachary Turner via lldb-dev 
You will probably need to debug the python code to figure out why this is
happening.  Start with this line in
lldb/packages/Python/lldbsuite/test/decorators.py
def _decorateTest(mode,
  bugnumber=None, oslist=None, hostoslist=None,
  compiler=None, compiler_version=None,
  archs=None, triple=None,
  debug_info=None,
  swig_version=None, py_version=None,
  macos_version=None,
  remote=None):
...
skip_for_compiler = _match_decorator_property(
compiler, self.getCompiler()) and
self.expectedCompilerVersion(compiler_version)


On Fri, Jan 6, 2017 at 10:11 AM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py has this
> decorator:
>
>
>
> @expectedFailureAll(compiler="clang", bugnumber="llvm.org/pr19238")
>
>
>
> On Linux, I’m building with hexagon-clang, and this decorator fires, so
> the test is xfailed.
>
> On Windows, I’m building with hexagon-clang.exe, and this decorator is
> evidently not firing, because the test fails instead of being xfailed.
>
>
>
> Linux is using Python 2.7.8. Windows is using Python 3.5.1.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 28026] LLDB-MI doesn't properly output CLI command response using console-stream-output stream

2017-01-06 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=28026

Aetf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] test decorator working on linux, but not on windows

2017-01-06 Thread Ted Woodward via lldb-dev 
Bottom line: lldbutil.is_exe() does not think “foo” is an exe on windows when 
“foo.exe” is.

 

 

 

print("***compiler is:", self.getCompiler(), file=sys.stderr)

 

***compiler is: 
C:\lldb\8.0\llvm\tools\lldb\packages\Python\lldbsuite\test\lang\c\typedef

 

self.getCompiler() is returning the test directory.

 

So, _decorateTest’s line:

skip_for_compiler = _match_decorator_property(compiler, 
self.getCompiler()) and self.expectedCompilerVersion(compiler_version)

is trying to match with the test directory.

 

On Linux I get this:

***compiler is: 
/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/toolset-4199/Tools/bin/clang-3.9

The path to the compiler (hexagon-clang is a symlink to clang-3.9).

 

Builder_base.getCompiler is:

def getCompiler():

"""Returns the compiler in effect the test suite is running with."""

compiler = os.environ.get("CC", "clang")

compiler = lldbutil.which(compiler)

return os.path.realpath(compiler)

 

os.environ.get returns 
r:/internal/branch-8.0/windows/latest/Tools/bin/hexagon-clang, but 
lldbutil.which returns None.

def which(program):

"""Returns the full path to a program; None otherwise."""

fpath, fname = os.path.split(program)

if fpath:

if is_exe(program):

return program

else:

for path in os.environ["PATH"].split(os.pathsep):

exe_file = os.path.join(path, program)

if is_exe(exe_file):

return exe_file

return None

 

The problem is the compiler – I specified hexagon-clang, not hexagon-clang.exe, 
so is_exe returns false.

def is_exe(fpath):

"""Returns True if fpath is an executable."""

return os.path.isfile(fpath) and os.access(fpath, os.X_OK)

 

 

 

My run line:

c:\lldb\8.0\35\Debug\libexec\python_d dotest.py -A v60 -C 
r:/internal/branch-8.0/windows/latest/Tools/bin/hexagon-clang --executable 
c:\lldb\8.0\35\Debug\bin\lldb.exe -t -v -p Testtypedef.py

 

Changing it to hexagon-clang.exe solved the problem.

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Zachary Turner [mailto:ztur...@google.com] 
Sent: Friday, January 06, 2017 12:17 PM
To: Ted Woodward ; LLDB 
Subject: Re: [lldb-dev] test decorator working on linux, but not on windows

 

You will probably need to debug the python code to figure out why this is 
happening.  Start with this line in 
lldb/packages/Python/lldbsuite/test/decorators.py

def _decorateTest(mode,

  bugnumber=None, oslist=None, hostoslist=None,

  compiler=None, compiler_version=None,

  archs=None, triple=None,

  debug_info=None,

  swig_version=None, py_version=None,

  macos_version=None,

  remote=None):

...

skip_for_compiler = _match_decorator_property(

compiler, self.getCompiler()) and 
self.expectedCompilerVersion(compiler_version)

 

 

On Fri, Jan 6, 2017 at 10:11 AM Ted Woodward via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py has this decorator:

 

@expectedFailureAll(compiler="clang", bugnumber="llvm.org/pr19238 
 ")

 

On Linux, I’m building with hexagon-clang, and this decorator fires, so the 
test is xfailed.

On Windows, I’m building with hexagon-clang.exe, and this decorator is 
evidently not firing, because the test fails instead of being xfailed.

 

Linux is using Python 2.7.8. Windows is using Python 3.5.1.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org  
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

2017-01-06 Thread Eugene Birukov via lldb-dev 
Hi,


It seems the problem is related to transparent huge pages. Disabling them helps.


The LLDB spins in this code:


[11428.634820] Call Trace:
[11428.634821]  [] do_huge_pmd_wp_page+0x62e/0xb80
[11428.634822]  [] handle_mm_fault+0x705/0xfe0
[11428.634823]  [] ? follow_page_mask+0x37d/0x7a0
[11428.634824]  [] __get_user_pages+0x19b/0x660
[11428.634825]  [] get_user_pages+0x52/0x60
[11428.634825]  [] __access_remote_vm+0xcb/0x1f0
[11428.634826]  [] access_process_vm+0x50/0x70
[11428.634827]  [] ptrace_request+0x2da/0x620
[11428.634828]  [] ? wait_task_inactive+0x16c/0x1f0
[11428.634829]  [] arch_ptrace+0x29b/0x300
[11428.634830]  [] SyS_ptrace+0xbe/0x110
[11428.634831]  [] system_call_fastpath+0x16/0x1b

Eugene


Sent from Outlook



From: Pavel Labath 
Sent: Tuesday, December 13, 2016 1:39 AM
To: Eugene Birukov
Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on 
Linux Ubuntu 16.04

Yeah, we support a couple of communication transports. For example, you can 
switch to using unix sockets instead. It's easiest if you just connect the 
server and client manually (for automatically starting up the server you would 
have to edit the source, I think.)

$ bin/lldb-server gdbserver unix-abstract:///tmp/X -- /bin/ls

$ bin/lldb
(lldb) process connect unix-abstract-connect:///tmp/X
Process 21731 stopped
* thread #1, name = 'ls', stop reason = signal SIGSTOP
frame #0: 0x7f4b341bb2d0
->  0x7f4b341bb2d0: movq   %rsp, %rdi
0x7f4b341bb2d3: callq  0x7f4b341bea40
0x7f4b341bb2d8: movq   %rax, %r12
0x7f4b341bb2db: movl   0x221b17(%rip), %eax


Good luck. Let me know what you find out.
pl


On 12 December 2016 at 18:11, Eugene Birukov 
mailto:eugen...@hotmail.com>> wrote:

OK, thanks!

I'll work on getting reliable repro on something I can attach kgdb to.


Meanwhile - is there any options in lldb-server communication protocol I could 
play with? Say, using pipe instead of tcp/ip or vice versa?


Sent from Outlook



From: Pavel Labath mailto:lab...@google.com>>
Sent: Friday, December 9, 2016 2:56 AM

To: Eugene Birukov
Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on 
Linux Ubuntu 16.04

It looks like debugging this remotely will not lead anywhere. I don't think I 
have enough knowledge about the kernel to help you with that. If I were able to 
reproduce it myself, maybe I'd get somewhere by random experiments, but doing 
it over the email is too slow. :)

I suggest you ask some of the kernel developers about it. They should be able 
to direct you where to look further, and may be aware of kernel changes between 
the two versions that would affect this.

cheers,
pl

On 8 December 2016 at 17:12, Eugene Birukov 
mailto:eugen...@hotmail.com>> wrote:

> From your description is sounds like un-predicability comes from the tracee 
> side


Not exactly. If problem is there, it repro's 100%. Things that affect repro - 
make it go away or shift to different address:


  1.  Delays in the client. If I put ::sleep(0) right after sending write 
memory request (not sure - are we writing in pipe or in socket?) - it might 
kill repro.
  2.  Changes in VM. Copying all bits into would be identical VM hurts repro.
  3.  Changes in the target application. I assume this is mainly layout of 
different VMA that shift after significant code change because target is fully 
stopped and it is hard to believe that the contents of the memory matters... 
Just in case - I tried to write different values and change write size to 8 
(not to trigger the recursion in llldb-server).

Things that do not matter:

  *   Delays in the server. As soon as we are about to call ptrace, no amount 
of delays caused by stepping, etc. matters, the damage is already there.

So, it seems that the problem is really not in ptrace but in the communication 
channel between the client and the server. Ptrace looks like just an innocent 
bystander caught in the gang crossfire on the street.


BTW, I am on short vacation, will be back on Monday 12/12.


Sent from Outlook



From: Pavel Labath mailto:lab...@google.com>>
Sent: Thursday, December 8, 2016 3:19 AM
To: Eugene Birukov

Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on 
Linux Ubuntu 16.04

Thanks for the info. I agree with your assessment, it definitely looks like a 
kernel bug.

I don't know how to trigger a kernel core dump. I have done a bit of kernel 
debugging/development, but it mainly consisted of adding a bunch of printf's 
and watching the dmesg output. I think we should contact the linux kernel 
mailing list (LKML.org) with this problem. I've had pretty good success with 
this in the past. The one contact I have there is Oleg Nesterov 
mailto:o...@redhat.com>>. He's quite a ptrace expert, and was 
able to fix my bug in a day when I contacte