date:20180716

Re: [lldb-dev] Linux: lldb tests are failed

2018-07-16 Thread Pavel Labath via lldb-dev

Hello Konstantin,

that sounds like a good idea. We've had reports of this in the past,
but so far noone dug into it to find out what's going on (thank you
for that). Can you create a review for this
(https://reviews.llvm.org/differential/)?

pl
On Mon, 9 Jul 2018 at 14:17, k.baladurin via lldb-dev
 wrote:
>
> Hello!
>
> Some lldb tests, for example test_hello_watchlocation_gmodules, are failed 
> due to UnicodeDecodeError:
>
> Config=x86_64-/home/jenkins/workspace/CS_for_Tizen/custom_test/llvm-x64/bin/clang-5.0
> ==
> ERROR: test_hello_watchlocation_gmodules 
> (TestWatchLocation.HelloWatchLocationTestCase)
>Test watching a location with '-s size' option.
> --
> Traceback (most recent call last):
>   File 
> "/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>  line 1752, in gmodules_test_method
> return attrvalue(self)
>   File 
> "/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/decorators.py",
>  line 110, in wrapper
> func(*args, **kwargs)
>   File 
> "/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/decorators.py",
>  line 110, in wrapper
> func(*args, **kwargs)
>   File 
> "/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/decorators.py",
>  line 110, in wrapper
> func(*args, **kwargs)
>   File 
> "/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/decorators.py",
>  line 110, in wrapper
> func(*args, **kwargs)
>   File 
> "/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/decorators.py",
>  line 110, in wrapper
> func(*args, **kwargs)
>   File 
> "/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py",
>  line 102, in test_hello_watchlocation
> self.runCmd("process continue")
>   File 
> "/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>  line 2070, in runCmd
> print(self.res.GetError(), file=sbuf)
>   File 
> "/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>  line 293, in __exit__
> print(self.getvalue(), file=self.session)
>   File 
> "/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/support/encoded_file.py",
>  line 34, in impl
> s = s.decode(encoding)
>   File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
> return codecs.utf_8_decode(input, errors, True)
> UnicodeDecodeError: 'utf8' codec can't decode byte 0xfb in position 257: 
> invalid start byte
>
> This error occurs when we try to decode following string:
>
> runCmd: process continue
> output: Process 579 resuming
> Process 579 stopped
> * thread #2, name = 'test_hello_watc', stop reason = watchpoint 1
> frame #0: 0x0040150f 
> test_hello_watchlocation_gmodules`do_bad_thing_with_location(char_ptr="\x01$\xad�,
>  new_val='\x01') at main.cpp:40
>37  unsigned what = new_val;
>38  printf("new value written to location(%p) = %u\n", char_ptr, 
> what);
>39  *char_ptr = new_val;
> -> 40  }
>41
>42  uint32_t
>43  access_pool (bool flag = false)
>
> Should we ignore such errors?
>
> With the following patch tests are passed:
>
> diff --git a/lldb/packages/Python/lldbsuite/support/encoded_file.py 
> b/lldb/packages/Python/lldbsuite/support/encoded_file.py
> index 2c2fef3..6412e76 100644
> --- a/lldb/packages/Python/lldbsuite/support/encoded_file.py
> +++ b/lldb/packages/Python/lldbsuite/support/encoded_file.py
> @@ -31,7 +31,7 @@ def _encoded_write(old_write, encoding):
>  # If we were asked to write a `str` (in Py2) or a `bytes` (in Py3) 
> decode it
>  # as unicode before attempting to write.
>  if isinstance(s, six.binary_type):
> -s = s.decode(encoding)
> +s = s.decode(encoding, 'ignore')
>  return old_write(s)
>  return impl
>
> Thank you!
>
> BR,
> Konstantin Baladurin
>
> ___
> 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] MI Handle events.

2018-07-16 Thread Pavel Labath via lldb-dev

The eStateSuspended state is used for threads (you can set it via
SBThread::Suspend/Resume). It controls whether a "continue" operation
on the process will run the thread or not.

I am not sure if you can ever see that state on the process itself.


On Sat, 14 Jul 2018 at 15:39, Adrian Prantl via lldb-dev
 wrote:
>
>
>
> > On Jul 13, 2018, at 10:59 PM, Александр Поляков  
> > wrote:
> >
> > Hi lldb-dev,
> >
> > I'm looking at re-implementing of 
> > CMICmnLLDBDebugHandleEvents::HandleProcessEventStateSuspended to get rid of 
> > HandleCommand("process status") hack and use SB API instead. To check my 
> > changes I need to get HandleProcessEventStateSuspended called, so could 
> > someone help me with a sequence of lldb-mi commands which will call 
> > HandleProcessEventStateSuspended.
>
> Other than reading through the code and manually tracing a sequence where 
> this function gets called, one simple trick you can try is to put an 
> assert(false) into HandleProcessEventStateSuspended, run the testsuite (or 
> perform an lldb-mi debug session) and look for a testacase that triggers the 
> new assertion.
>
> -- adrian
>
> >
> > Thanks in advance.
> >
> > --
> > Alexander
>
> ___
> 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] Linux: lldb tests are failed

2018-07-16 Thread k.baladurin via lldb-dev


Hello Pavel,

Thank you for replying! I've created a review for this change: 
https://reviews.llvm.org/D49379


BR,
Konstantin Baladurin


On 16.07.2018 13:45, Pavel Labath wrote:

Hello Konstantin,

that sounds like a good idea. We've had reports of this in the past,
but so far noone dug into it to find out what's going on (thank you
for that). Can you create a review for this
(https://reviews.llvm.org/differential/)?

pl
On Mon, 9 Jul 2018 at 14:17, k.baladurin via lldb-dev
 wrote:

Hello!

Some lldb tests, for example test_hello_watchlocation_gmodules, are failed due 
to UnicodeDecodeError:

Config=x86_64-/home/jenkins/workspace/CS_for_Tizen/custom_test/llvm-x64/bin/clang-5.0
==
ERROR: test_hello_watchlocation_gmodules 
(TestWatchLocation.HelloWatchLocationTestCase)
Test watching a location with '-s size' option.
--
Traceback (most recent call last):
   File 
"/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 1752, in gmodules_test_method
 return attrvalue(self)
   File 
"/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/decorators.py",
 line 110, in wrapper
 func(*args, **kwargs)
   File 
"/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/decorators.py",
 line 110, in wrapper
 func(*args, **kwargs)
   File 
"/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/decorators.py",
 line 110, in wrapper
 func(*args, **kwargs)
   File 
"/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/decorators.py",
 line 110, in wrapper
 func(*args, **kwargs)
   File 
"/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/decorators.py",
 line 110, in wrapper
 func(*args, **kwargs)
   File 
"/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py",
 line 102, in test_hello_watchlocation
 self.runCmd("process continue")
   File 
"/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2070, in runCmd
 print(self.res.GetError(), file=sbuf)
   File 
"/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 293, in __exit__
 print(self.getvalue(), file=self.session)
   File 
"/home/jenkins/workspace/CS_for_Tizen/custom_test/lldb/packages/Python/lldbsuite/support/encoded_file.py",
 line 34, in impl
 s = s.decode(encoding)
   File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
 return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xfb in position 257: 
invalid start byte

This error occurs when we try to decode following string:

runCmd: process continue
output: Process 579 resuming
Process 579 stopped
* thread #2, name = 'test_hello_watc', stop reason = watchpoint 1
 frame #0: 0x0040150f 
test_hello_watchlocation_gmodules`do_bad_thing_with_location(char_ptr="\x01$\xad�,
 new_val='\x01') at main.cpp:40
37  unsigned what = new_val;
38  printf("new value written to location(%p) = %u\n", char_ptr, 
what);
39  *char_ptr = new_val;
-> 40  }
41
42  uint32_t
43  access_pool (bool flag = false)

Should we ignore such errors?

With the following patch tests are passed:

diff --git a/lldb/packages/Python/lldbsuite/support/encoded_file.py 
b/lldb/packages/Python/lldbsuite/support/encoded_file.py
index 2c2fef3..6412e76 100644
--- a/lldb/packages/Python/lldbsuite/support/encoded_file.py
+++ b/lldb/packages/Python/lldbsuite/support/encoded_file.py
@@ -31,7 +31,7 @@ def _encoded_write(old_write, encoding):
  # If we were asked to write a `str` (in Py2) or a `bytes` (in Py3) 
decode it
  # as unicode before attempting to write.
  if isinstance(s, six.binary_type):
-s = s.decode(encoding)
+s = s.decode(encoding, 'ignore')
  return old_write(s)
  return impl

Thank you!

BR,
Konstantin Baladurin

___
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] Linux: Failing lldb unit tests and TestLinuxCore.py

2018-07-16 Thread Pavel Labath via lldb-dev

Hi Gábor,

sorry for the late reply, I have been OOO. Thanks for the detailed
report. I think the fact that we load the system lldb from the unit
tests should be considered a bug. I am going to try to find some time
fix this issue.

thanks,
pl
On Fri, 29 Jun 2018 at 15:35, Gábor Márton  wrote:
>
> So, on Ubuntu "sudo apt-get remove python-lldb-4.0" solved this issue.
> Thanks again for the guidance.
>
> Cheers,
> Gabor
>
> On Fri, Jun 29, 2018 at 4:10 PM Gábor Márton  wrote:
>>
>> I did a search for the "HLOp" symbol and it turned out it is only used by 
>> the "LLVMSupport.so" lib.
>> So, this did not help, thus I dug deeper and examined the test binary 
>> further.
>>
>> `_exit` is called during the initialization of the static HLOp object 
>> (dlopen() calls call_init() which executes the static initialization of the 
>> object).
>> But for some strange reason it turned out the init function 
>> (llvm::cl::OptionCategory::registerCategory()) is called from 
>> /usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1 .
>> So then I used strace to find out that first "libLLVMSupport.so.7" is loaded 
>> by the dynamic loader and then later the " 
>> /usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1". Both have the 
>> `registerCategory()` function called during the load of the lib and the 
>> second call causes the error.
>> The sequence of the `open` syscalls shows that my local python installation 
>> brings in my local lldb lib which in turn loads the local libLLVM lib. And 
>> this is the problem. Below attached the detailed log of the open calls.
>> One solution is to uninstall my local lldb or use a different python, or use 
>> a virtual env for python - which does not contain any lldb modules - when 
>> running these tests.
>> Perhaps, somehow we could discover with cmake that the local python install 
>> contains lldb and issue a diagnostic in that case, but this seems quite 
>> complicated.
>>
>> Thanks,
>> Gabor
>>
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/tls/x86_64/libgtest_main.so.7",
>>  O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/tls/libgtest_main.so.7",
>>  O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/x86_64/libgtest_main.so.7",
>>  O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libgtest_main.so.7", 
>> O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libgtest.so.7", 
>> O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libpython2.7.so.1.0",
>>  O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>> open("/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0", O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMDemangle.so.7",
>>  O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangFrontend.so.7",
>>  O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMExecutionEngine.so.7",
>>  O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMCore.so.7", 
>> O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMRuntimeDyld.so.7",
>>  O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangCodeGen.so.7",
>>  O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangDriver.so.7",
>>  O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangEdit.so.7", 
>> O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangParse.so.7", 
>> O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangRewrite.so.7",
>>  O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangSema.so.7", 
>> O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMMCJIT.so.7", 
>> O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangBasic.so.7", 
>> O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMDebugInfoDWARF.so.7",
>>  O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangLex.so.7", 
>> O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMDebugInfoPDB.so.7",
>>  O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMSupport.so.7",
>>  O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libpthread.so.0", 
>> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
>> open("/home/egbomrt/WORK/llvm3/bu

Re: [lldb-dev] Linux: lldb tests are failed

Re: [lldb-dev] MI Handle events.

Re: [lldb-dev] Linux: lldb tests are failed

Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py

4 matches

Site Navigation

Mail list logo

Footer information