[lldb-dev] Selectively disabling value formatter

[Vadim Chugunov via lldb-dev]

Hi,
If I have an SBValue for an object whose type has a formatter enabled for
it, is there a way to detect this via the Python API, and if so, request an
"unmodified" view of the object?
I've experimented with value.IsSynthetic() and
value.GetNonSyntheticValue(), but the former seems to always return false,
and the latter gives me the same list of children as the original value.

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

Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Daniel Sanders via lldb-dev]

I have some proper rc1 results now.

clang+llvm-3.8.0-rc1-mips-linux-gnu.tar.xz
test-release.sh refused to run 'make check-all' because libcxx_tsan 
failed to configure. This is because the thread sanitizer is not supported on 
MIPS32.
After working around this (patch will follow shortly):
~200 sanitizer failures. Most of them tsan (which as noted 
above shouldn't be running), but other sanitizers too.
lots of libc++ failures split into two cases:
(No ticket yet) - Missing builtins for 64-bit atomics. 
Vasileios Kalintiris has given me a patch that should fix this
PR26277 - Some diagnostic checking tests fail because the 
assembler can't find it's input file. Clang didn't create it due to frontend 
errors but still called GAS.

clang+llvm-3.8.0-rc1-mipsel-linux-gnu.tar.xz
lots of libc++ failures split into two cases:
(No ticket yet) - Missing builtins for 64-bit atomics. 
Vasileios Kalintiris has given me a patch that should fix this
PR26277 - Some diagnostic checking tests fail because the 
assembler can't find it's input file. Clang didn't create it due to frontend 
errors but still called GAS.
Test-suite was ok.

clang+llvm-3.8.0-rc1-x86_64-linux-gnu-debian8.tar.xz (native X86_64)
PR26252 - libc++ fails 23 tests due to missing en_US-UTF8 locale. I 
have two patches in progress for this and I've also made the problem go away by 
enabling this locale.
PR26253 - libomp fails runtime/test/barrier/omp_barrier.c
Test-suite was ok

clang+llvm-3.8.0-rc1-x86_64-linux-gnu-debian8.tar.xz (cross compiling to Mips)
10/23 test-suite configs ok. The rest are still running.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Ubuntu version-based fail/skip

[Tamas Berghammer via lldb-dev]

I think recently we are trying to reduce the number of decorators we are
having so adding a few new Ubuntu specific decorators might not be a good
idea. My suggestion would be to move on a little bit to the functional
programming style with adding a new option to @expetedFailureAll where we
can specify a function what have to evaluate to true for the decorator to
be considered (and it is evaluated only after all other condition of
@expectedFailureAll). Then we can create a free function called
getLinuxDistribution what will return the distribution id and then as a
final step we can specify a lambda to expetedFailureAll through its new
argument what calls getLinuxDistribution and compares it with the right
value. I know it is a lot of hoops to jump over to get a distribution
specific decorator but I think this approach can handle arbitrarily complex
skip/xfail conditions what will help us in the future.

What do you think?

Thanks,
Tamas


On Fri, Jan 22, 2016 at 6:31 PM Todd Fiala  wrote:

> Hey all,
>
> What do you think about having some kind of way of marking the (in this
> case, specifically) Ubuntu distribution for fail/skip test decorators?
> I've had a few cases where I've needed to mark tests failing on for Ubuntu
> where it really was only a particular release of an Ubuntu distribution,
> and wasn't specifically the compiler.  (i.e. it was a constellation of more
> moving parts that clearly occur on a particular release of an Ubuntu
> distribution but not on others, and certainly not generically across all
> Linux distributions).
>
> I'd love to have a way to skip and xfail a test for a specific Ubuntu
> distribution release.  I guess it could be done uber-genrically, but with
> Linux distributions this can get complicated due to the os/distribution
> axes.  So I'd be happy to start off with just having them at a distribution
> basis:
>
> @skipIfUbuntu(version_check_list)  # version_check_list contains one or
> more version checks that, if passing, trigger the skip
>
> @expectedFailureUbuntu(version_check_list)  # similar to above
>
> Or possibly more usefully,
>
> @skipIfLinuxDistribution(version_check_list)  # version_check_list
> contains one or more version checks that, if passing, trigger the skip,
> includes the distribution
>
> @expectedFailureLinuxDistribution(version_check_list)  # similar to above
>
>
> It's not clear to me how to work in the os=linux, distribution=Ubuntu into
> the more generic checks like and get distribution-level version checking
> working right otherwise, but I'm open to suggestions.
>
> The workaround for the short term is to just use blanket-linux @skipIf and
> @expectedFailure style calls.
>
> Thoughts?
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 26289] New: lldb host crashes with allocation failure when attaching to a remote android target

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26289

Bug ID: 26289
   Summary: lldb host crashes with allocation failure when
attaching to a remote android target
   Product: lldb
   Version: unspecified
  Hardware: Other
OS: other
Status: NEW
  Severity: release blocker
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: luke.drumm...@codeplay.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15704
  --> https://llvm.org/bugs/attachment.cgi?id=15704&action=edit
attempting to attach to a remote android process with all logging enabled

lldb as of r258122 is crashing during process attach to a remote Android x86_64
target due to a `std::bad_alloc` being raised during the process of loading
symbols.

## Short log (log enable lldb all is attached)
```
(lldb) log enable lldb process
(lldb) log enable lldb language
(lldb) log enable lldb expression
(lldb) platform select remote-android
  Platform: remote-android
 Connected: no
(lldb) platform connect connect://localhost:1234
  Platform: remote-android
Triple: x86_64-*-linux
OS Version: 23.0.0 (3.10.0+)
Kernel: #24 PREEMPT Fri Oct 30 16:57:39 PDT 2015
  Hostname: localhost
 Connected: yes
WorkingDir: /
(lldb) process attach -p 2744
Process::SetPrivateState (connected)
Process::ControlPrivateStateThread (signal = 4)
Sending control event of type: 4.
Process::RunPrivateStateThread (arg = 0xb12b30, pid = 0) thread starting...
Process::WaitForEventsPrivate (timeout = (nil), event_sp)...
Process::RunPrivateStateThread (arg = 0xb12b30, pid = 0) got a control event: 4
Process::WaitForEventsPrivate (timeout = (nil), event_sp)...
Process::ShouldBroadcastEvent (0xb34290) => new state: connected, last
broadcast state: connected - YES
Process::HandlePrivateEvent (pid = 0) broadcasting new state connected (old
state unloaded) to hijacked
Process::SetPublicState (state = attaching, restarted = 0)
Process::WaitForEventsPrivate (timeout = (nil), event_sp)...
Process::AttachCompletionHandler::AttachCompletionHandler process=0xb12b30,
exec_count=0
Process::WaitForProcessToStop (timeout = (nil))
Process::WaitForStateChangedEvents (timeout = (nil), event_sp)...
Process::SetPublicState (state = connected, restarted = 0)
Process::WaitForStateChangedEvents (timeout = (nil), event_sp) => connected
Process::WaitForStateChangedEvents (timeout = (nil), event_sp)...
Process::SetPrivateState (stopped)
Process::SetPrivateState (stopped) stop_id = 1
Process::AttachCompletionHandler::PerformAction called with state stopped (5)
Process::AttachCompletionHandler::PerformAction state stopped: no more execs
expected to start, continuing with attach
Process::CompleteAttach()
Process::CompleteAttach replacing process architecture with DidAttach()
architecture: x86_64--linux-android
ProcessGDBRemote::GetLoadedModuleList
ProcessGDBRemote::GetLoadedModuleList
ProcessGDBRemote::GetLoadedModuleList
ProcessGDBRemote::GetLoadedModuleList
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted
```

## Backtrace

```
* thread #4: tid = 9129, 0x7f51a4374cc9 libc.so.6`gsignal + 57, name =
'intern-state', stop reason = signal SIGABRT
  * frame #0: 0x7f51a4374cc9 libc.so.6`gsignal + 57
frame #1: 0x7f51a43780d8 libc.so.6`abort + 328
frame #2: 0x7f51a4763535
libstdc++.so.6`__gnu_cxx::__verbose_terminate_handler() + 341
frame #3: 0x7f51a47616d6 libstdc++.so.6`??? + 6
frame #4: 0x7f51a4761703 libstdc++.so.6`std::terminate() + 19
frame #5: 0x7f51a4761922 libstdc++.so.6`__cxa_throw + 114
frame #6: 0x7f51a4761e0d libstdc++.so.6`operator new(unsigned long) +
125
frame #7: 0x7f51a5683a82
liblldb.so.3.9.0`__gnu_cxx::new_allocator::allocate(this=0x7f519efc1e40, __n=4720169055844,
(null)=0x) + 60 at new_allocator.h:104
frame #8: 0x7f51a56836d7 liblldb.so.3.9.0`std::_Vector_base >::_M_allocate(this=0x7f519efc1e40,
__n=4720169055844) + 47 at stl_vector.h:168
frame #9: 0x7f51a592bb91 liblldb.so.3.9.0`std::_Vector_base
>::_M_create_storage(this=0x7f519efc1e40, __n=4720169055844) + 35 at
stl_vector.h:181
frame #10: 0x7f51a59294ae liblldb.so.3.9.0`std::_Vector_base >::_Vector_base(this=0x7f519efc1e40,
__n=4720169055844, __a=0x7f5194046908) + 58 at stl_vector.h:136
frame #11: 0x7f51a668725f liblldb.so.3.9.0`std::vector >::vector(this=0x7f519efc1e40,
__n=4720169055844, __value=0x7f519efc1ebc, __a=0x7f5194046908) + 47 at
stl_vector.h:283
frame #12: 0x7f51a6696d59 liblldb.so.3.9.0`std::vector >::_M_fill_assign(this=0x7f5194046908,
__n=4720169055844, __val=0x7f519efc1ebc) + 79 at vector.tcc:223
frame #13: 0x7f51a6696b8b liblldb.so.3.9.0`std::vector >::assign(this=0x7f5194046908,
__n=4720169055844, __val=0x7f519

Re: [lldb-dev] [cfe-dev] [3.8 Release] RC1 has been tagged

[Hans Wennborg via lldb-dev]

On Sun, Jan 24, 2016 at 2:48 PM, Brian Cain  wrote:
>
> On Thu, Jan 21, 2016 at 9:52 PM, Brian Cain  wrote:
>>
>> On Thu, Jan 21, 2016 at 8:31 PM, Eric Fiselier  wrote:
>>>
>>>
>>> On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev
>>>  wrote:

 SuSE Linux Enterprise Server 11SP3 x86_64

 Looks like I see several failures that weren't in 3.7.1.  Is there any
 way to tell whether these are regressions vs new-to-3.8.0-but-failing?  The
 MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were
 not in 3.7.1.

>>>
>>> All of the libc++ failures seem like non-issues and should be in 3.7.1.
>>> Did you change or upgrade your platform or libc version?  I'm not sure about
>>> the libc++abi error though.
>>
>>
>> I don't recall any changes to libc.  Attached is the testing log from
>> 3.7.1 rc2 (I don't have logs from -final handy).
>>
>> I can repeat a 3.7.1 release build on this system now.  I don't think the
>> results will change, though.
>>
>
> I discussed this more with Eric off-list and I think we've come to the
> conclusion that this was not a regression, it was my error.
>
> It's a bit tricky -- what should I expect for a new platform?  All failing
> tests are likely failing because they can't be/aren't yet supported?  It's
> tough to distinguish -- are they real bugs to be fixed, errors in the
> build/release process?

Ideally, all tests should pass on the platforms we build for. In your
case, it's not even very exotic, just x86_64 Linux. The LLVM and Clang
tests are pretty good in this regard, but various sanitizer and libc++
tests seem less stable. In practice, we've been releasing as long as
the failures don't look like regressions from previous releases.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux

[Hans Wennborg via lldb-dev]

This patch looks reasonable to me, but I don't know enough about LLDB
to actually review it.

+Renato or Pavel maybe?

On Thu, Jan 14, 2016 at 11:32 AM, William Dillon via lldb-dev
 wrote:
> Hi again, everyone
>
> I’d like to ping on this patch now that the 3.8 branch is fairly new, and 
> merging it over is fairly straight-forward.
>
> Thanks in advance for your comments!
> - Will
>
>> There is a small change that enables correct calculation of arm sub 
>> architectures while using the REPL on arm-linux.  As you may of may or may 
>> not know, linux appends ‘l’ to arm architecture versions to denote little 
>> endian.  This sometimes interferes with the determination of the 
>> architecture in the triple.  I experimented with adding sub architecture 
>> entries for these within lldb, but I discovered a simpler (and less 
>> invasive) method.  Because LLVM already knows how to handle some of these 
>> cases (I have a patch submitted for review that enables v6l; v7l already 
>> works), I am relying on llvm to clean it up.  The gist of it is that the 
>> llvm constructor (when given a triple string) retains the provided string 
>> unless an accessor mutates it.  Meanwhile, the accessors for the components 
>> go through the aliasing and parsing logic.  This code detects whether the 
>> sub-architecture that armv6l or armv7l aliases to is detected, and re-sets 
>> the architecture in the triple.  This overwrites the architecture that comes 
>> from linux, thus sanitizing it.
>>
>> Some kind of solution is required for the REPL to work on arm-linux.  
>> Without it, the REPL crashes.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Selectively disabling value formatter

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 12:23 AM, Vadim Chugunov via lldb-dev 
>  wrote:
> 
> Hi,
> If I have an SBValue for an object whose type has a formatter enabled for it, 
> is there a way to detect this via the Python API, and if so, request an 
> "unmodified" view of the object?

There definitely is a way for synthetic children, as you discovered below
For type formats, you can simply set the format on the SBValue on an individual 
basis (SBValue::SetFormat)
As for summaries, no, there is no way, as that would be nonsensical (don’t like 
the summary? just don’t ask for it - but there’s no meaning to getting the 
summary of a value once you disabled its summary)

> I've experimented with value.IsSynthetic() and value.GetNonSyntheticValue(), 
> but the former seems to always return false, and the latter gives me the same 
> list of children as the original value.

Do you have a reproduction case I can look at?
GetNonSyntheticValue() returning self is correct behavior if IsSynthetic() == 
False; but if there really is a synthetic provider attached to the object, 
IsSynthetic() should definitely return True

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


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

[lldb-dev] Bad state of release 3.7.1?

[Jeffrey Tan via lldb-dev]

Hi,

My colleague downloaded and built 3.7.1 version of lldb on Linux. When we
used it to attach to a normal process(like sleep), it just hangs forever:

bin/lldb -n sleep
(lldb) process attach --name "sleep"

And my private built 3.8.0 version works fine.

Just to confirm, is 3.7.1 a bad version? Is there any known issue about it?

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

Re: [lldb-dev] Selectively disabling value formatter

[Vadim Chugunov via lldb-dev]

On Mon, Jan 25, 2016 at 11:04 AM, Enrico Granata  wrote:

>
> On Jan 25, 2016, at 12:23 AM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
> If I have an SBValue for an object whose type has a formatter enabled for
> it, is there a way to detect this via the Python API, and if so, request an
> "unmodified" view of the object?
>
>
> There definitely is a way for synthetic children, as you discovered below
> For type formats, you can simply set the format on the SBValue on an
> individual basis (SBValue::SetFormat)
> As for summaries, no, there is no way, as that would be nonsensical (don’t
> like the summary? just don’t ask for it - but there’s no meaning to getting
> the summary of a value once you disabled its summary)
>

Yes, this is about synthetic children.  Summaries are not a problem.


>
> I've experimented with value.IsSynthetic() and
> value.GetNonSyntheticValue(), but the former seems to always return false,
> and the latter gives me the same list of children as the original value.
>
>
> Do you have a reproduction case I can look at?
>

My setup is kinda complicated, I want to make sure I am using the API
correctly before attempting to create a self-contained repro case.


> GetNonSyntheticValue() returning self is correct behavior if IsSynthetic()
> == False; but if there really is a synthetic provider attached to the
> object, IsSynthetic() should definitely return True
>
>
Whose IsSynthetic() is supposed to return True,- the parent's or the
child's?
And on which object should I be calling GetNonSyntheticValue()?  (I assume
on the parent?)

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

Re: [lldb-dev] Selectively disabling value formatter

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 3:20 PM, Vadim Chugunov  wrote:
> 
> On Mon, Jan 25, 2016 at 11:04 AM, Enrico Granata  > wrote:
> 
>> On Jan 25, 2016, at 12:23 AM, Vadim Chugunov via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Hi,
>> If I have an SBValue for an object whose type has a formatter enabled for 
>> it, is there a way to detect this via the Python API, and if so, request an 
>> "unmodified" view of the object?
> 
> There definitely is a way for synthetic children, as you discovered below
> For type formats, you can simply set the format on the SBValue on an 
> individual basis (SBValue::SetFormat)
> As for summaries, no, there is no way, as that would be nonsensical (don’t 
> like the summary? just don’t ask for it - but there’s no meaning to getting 
> the summary of a value once you disabled its summary)
> 
> Yes, this is about synthetic children.  Summaries are not a problem.
>  
> 
>> I've experimented with value.IsSynthetic() and value.GetNonSyntheticValue(), 
>> but the former seems to always return false, and the latter gives me the 
>> same list of children as the original value.
> 
> Do you have a reproduction case I can look at?
> 
> My setup is kinda complicated, I want to make sure I am using the API 
> correctly before attempting to create a self-contained repro case.
>  

That’s fair. Can you at least try to describe what you’re trying to do and the 
data types involved in this?

> GetNonSyntheticValue() returning self is correct behavior if IsSynthetic() == 
> False; but if there really is a synthetic provider attached to the object, 
> IsSynthetic() should definitely return True
> 
> 
> Whose IsSynthetic() is supposed to return True,- the parent's or the child's? 
>  

What do you mean with this?
The model is that you have an SBValue, and that SBValue could be backed by a 
synthetic value. If you want, you can LLDB not to prefer synthetic values - 
which changes the way the current SBValue works - or for the same backing 
variable, give you a non-synthetic SBValue, which is what 
GetNonSyntheticValue() does

Parent/child should have nothing to do with this, unless I am misunderstanding 
you

> And on which object should I be calling GetNonSyntheticValue()?  (I assume on 
> the parent?)
> 
> Vadim


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [lldb-dev] Bad state of release 3.7.1?

[Jeffrey Tan via lldb-dev]

Btw: here is the source that we built lldb from:

http://llvm.org/releases/download.html#3.7.1

direct link http://llvm.org/releases/3.7.1/lldb-3.7.1.src.tar.xz

On Mon, Jan 25, 2016 at 2:37 PM, Jeffrey Tan 
wrote:

> Hi,
>
> My colleague downloaded and built 3.7.1 version of lldb on Linux. When we
> used it to attach to a normal process(like sleep), it just hangs forever:
>
> bin/lldb -n sleep
> (lldb) process attach --name "sleep"
>
> And my private built 3.8.0 version works fine.
>
> Just to confirm, is 3.7.1 a bad version? Is there any known issue about it?
>
> Thanks
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Selectively disabling value formatter

[Siva Chandra via lldb-dev]

On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov via lldb-dev
 wrote:
> Hi,
> If I have an SBValue for an object whose type has a formatter enabled for
> it, is there a way to detect this via the Python API, and if so, request an
> "unmodified" view of the object?
> I've experimented with value.IsSynthetic() and value.GetNonSyntheticValue(),
> but the former seems to always return false, and the latter gives me the
> same list of children as the original value.

This was a problem way back in June '15 and Enrico fixed it. Which
version of LLDB are you using?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Selectively disabling value formatter

[Vadim Chugunov via lldb-dev]

lldb-340.4.119 (OSX 10.11.3)

On Mon, Jan 25, 2016 at 3:42 PM, Siva Chandra 
wrote:

> On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov via lldb-dev
>  wrote:
> > Hi,
> > If I have an SBValue for an object whose type has a formatter enabled for
> > it, is there a way to detect this via the Python API, and if so, request
> an
> > "unmodified" view of the object?
> > I've experimented with value.IsSynthetic() and
> value.GetNonSyntheticValue(),
> > but the former seems to always return false, and the latter gives me the
> > same list of children as the original value.
>
> This was a problem way back in June '15 and Enrico fixed it. Which
> version of LLDB are you using?
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Selectively disabling value formatter

[Siva Chandra via lldb-dev]

On Mon, Jan 25, 2016 at 4:09 PM, Vadim Chugunov  wrote:
> lldb-340.4.119 (OSX 10.11.3)

I have no idea what that number means. May be Enrico can figure if
that build has the fix or not.

> On Mon, Jan 25, 2016 at 3:42 PM, Siva Chandra 
> wrote:
>>
>> On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov via lldb-dev
>>  wrote:
>> > Hi,
>> > If I have an SBValue for an object whose type has a formatter enabled
>> > for
>> > it, is there a way to detect this via the Python API, and if so, request
>> > an
>> > "unmodified" view of the object?
>> > I've experimented with value.IsSynthetic() and
>> > value.GetNonSyntheticValue(),
>> > but the former seems to always return false, and the latter gives me the
>> > same list of children as the original value.
>>
>> This was a problem way back in June '15 and Enrico fixed it. Which
>> version of LLDB are you using?
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Selectively disabling value formatter

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 4:04 PM, Vadim Chugunov  wrote:
> 
> 
> 
> On Mon, Jan 25, 2016 at 3:31 PM, Enrico Granata  > wrote:
> 
>> 
>> Whose IsSynthetic() is supposed to return True,- the parent's or the 
>> child's?  
> 
> What do you mean with this?
> The model is that you have an SBValue, and that SBValue could be backed by a 
> synthetic value. If you want, you can LLDB not to prefer synthetic values - 
> which changes the way the current SBValue works - or for the same backing 
> variable, give you a non-synthetic SBValue, which is what 
> GetNonSyntheticValue() does
> 
> Parent/child should have nothing to do with this, unless I am 
> misunderstanding you
> 
> I guess I am confused about what "synthetic" refers to.  Let's say I have an 
> SBValue representing std::vector and stl formatters are enabled.   As far as 
> I understand, that SBValue itself (the parent) would be considered "real", 
> but its children (the vector elements) would be "synthetic" (because they 
> were generated by formatter).
> 

In your scenario, the SBValue for the vector is synthetic; the SBValue 
instances for each of the vector elements are not synthetic (well, unless, they 
are themselves vectors or other things with synthetic providers)

Does that match what you’re seeing?

> Vadim


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [lldb-dev] Selectively disabling value formatter

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 4:09 PM, Vadim Chugunov via lldb-dev 
>  wrote:
> 
> lldb-340.4.119 (OSX 10.11.3)
> 
> On Mon, Jan 25, 2016 at 3:42 PM, Siva Chandra  > wrote:
> On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> > Hi,
> > If I have an SBValue for an object whose type has a formatter enabled for
> > it, is there a way to detect this via the Python API, and if so, request an
> > "unmodified" view of the object?
> > I've experimented with value.IsSynthetic() and value.GetNonSyntheticValue(),
> > but the former seems to always return false, and the latter gives me the
> > same list of children as the original value.
> 
> This was a problem way back in June '15 and Enrico fixed it. Which
> version of LLDB are you using?
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


I have a hard time recalling which fix that was, I can look up old logs
With that said, if the fix happened in June ’15, it’s unlikely to be in lldb-340

I would encourage you to use trunk LLDB and see if that works better in your 
use case

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [lldb-dev] Bad state of release 3.7.1?

[Jeffrey Tan via lldb-dev]

Thanks David.
I am new to lldb group but it's kind of surprise to me that the lldb on the
official release page(http://llvm.org/releases/download.html#3.7.1) can
have such big problems(can't attach/launch). Don't we fully test lldb
before we post on the official website?



On Mon, Jan 25, 2016 at 4:12 PM, David Jones  wrote:

> This is a known problem with 3.7.1.
>
> It should be fixed for 3.8. You should be able to try out 3.8rc1 right now.
>
>
>
> On Mon, Jan 25, 2016 at 5:37 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi,
>>
>> My colleague downloaded and built 3.7.1 version of lldb on Linux. When we
>> used it to attach to a normal process(like sleep), it just hangs forever:
>>
>> bin/lldb -n sleep
>> (lldb) process attach --name "sleep"
>>
>> And my private built 3.8.0 version works fine.
>>
>> Just to confirm, is 3.7.1 a bad version? Is there any known issue about
>> it?
>>
>> Thanks
>>
>> ___
>> 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] Bad state of release 3.7.1?

[Jeffrey Tan via lldb-dev]

Btw: is there a fix that we can cherry pick? Or is it safe for us to build
lldb 3.8rc1 with llvm3.7.1?

On Mon, Jan 25, 2016 at 4:34 PM, Jeffrey Tan 
wrote:

> Thanks David.
> I am new to lldb group but it's kind of surprise to me that the lldb on
> the official release page(http://llvm.org/releases/download.html#3.7.1)
> can have such big problems(can't attach/launch). Don't we fully test lldb
> before we post on the official website?
>
>
>
> On Mon, Jan 25, 2016 at 4:12 PM, David Jones 
> wrote:
>
>> This is a known problem with 3.7.1.
>>
>> It should be fixed for 3.8. You should be able to try out 3.8rc1 right
>> now.
>>
>>
>>
>> On Mon, Jan 25, 2016 at 5:37 PM, Jeffrey Tan via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> My colleague downloaded and built 3.7.1 version of lldb on Linux. When
>>> we used it to attach to a normal process(like sleep), it just hangs forever:
>>>
>>> bin/lldb -n sleep
>>> (lldb) process attach --name "sleep"
>>>
>>> And my private built 3.8.0 version works fine.
>>>
>>> Just to confirm, is 3.7.1 a bad version? Is there any known issue about
>>> it?
>>>
>>> Thanks
>>>
>>> ___
>>> 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] Selectively disabling value formatter

[Siva Chandra via lldb-dev]

I think this one:
http://llvm.org/viewvc/llvm-project?view=revision&revision=240578

On Mon, Jan 25, 2016 at 4:34 PM, Enrico Granata  wrote:

>
> On Jan 25, 2016, at 4:09 PM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> lldb-340.4.119 (OSX 10.11.3)
>
> On Mon, Jan 25, 2016 at 3:42 PM, Siva Chandra 
> wrote:
>
>> On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov via lldb-dev
>>  wrote:
>> > Hi,
>> > If I have an SBValue for an object whose type has a formatter enabled
>> for
>> > it, is there a way to detect this via the Python API, and if so,
>> request an
>> > "unmodified" view of the object?
>> > I've experimented with value.IsSynthetic() and
>> value.GetNonSyntheticValue(),
>> > but the former seems to always return false, and the latter gives me the
>> > same list of children as the original value.
>>
>> This was a problem way back in June '15 and Enrico fixed it. Which
>> version of LLDB are you using?
>>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> I have a hard time recalling which fix that was, I can look up old logs
> With that said, if the fix happened in June ’15, it’s unlikely to be in
> lldb-340
>
> I would encourage you to use trunk LLDB and see if that works better in
> your use case
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Selectively disabling value formatter

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 4:48 PM, Siva Chandra  wrote:
> 
> I think this one: 
> http://llvm.org/viewvc/llvm-project?view=revision&revision=240578 
> 
> 
> On Mon, Jan 25, 2016 at 4:34 PM, Enrico Granata  > wrote:
> 
>> On Jan 25, 2016, at 4:09 PM, Vadim Chugunov via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> lldb-340.4.119 (OSX 10.11.3)
>> 
>> On Mon, Jan 25, 2016 at 3:42 PM, Siva Chandra > > wrote:
>> On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov via lldb-dev
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> > Hi,
>> > If I have an SBValue for an object whose type has a formatter enabled for
>> > it, is there a way to detect this via the Python API, and if so, request an
>> > "unmodified" view of the object?
>> > I've experimented with value.IsSynthetic() and 
>> > value.GetNonSyntheticValue(),
>> > but the former seems to always return false, and the latter gives me the
>> > same list of children as the original value.
>> 
>> This was a problem way back in June '15 and Enrico fixed it. Which
>> version of LLDB are you using?
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> 
> 
> 
> I have a hard time recalling which fix that was, I can look up old logs
> With that said, if the fix happened in June ’15, it’s unlikely to be in 
> lldb-340
> 
> I would encourage you to use trunk LLDB and see if that works better in your 
> use case
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 
> 

Yeah, I don’t think that that change made into lldb-340

That might be the root cause of Vadim’s issue. Thanks for pointing that out 
Siva.

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [lldb-dev] Bad state of release 3.7.1?

[David Jones via lldb-dev]

 r246756 has a fix, if you are comfortable applying it. It's a large patch.
In theory it should back-port but I have not tried it.

The API gap from 3.7.1 to 3.8 is quite minimal, so you should be able to
get your applications running with 3.8 rather easily if they are running on
3.7.1 already.


On Mon, Jan 25, 2016 at 7:40 PM, Jeffrey Tan 
wrote:

> Btw: is there a fix that we can cherry pick? Or is it safe for us to build
> lldb 3.8rc1 with llvm3.7.1?
>
> On Mon, Jan 25, 2016 at 4:34 PM, Jeffrey Tan 
> wrote:
>
>> Thanks David.
>> I am new to lldb group but it's kind of surprise to me that the lldb on
>> the official release page(http://llvm.org/releases/download.html#3.7.1)
>> can have such big problems(can't attach/launch). Don't we fully test lldb
>> before we post on the official website?
>>
>>
>>
>> On Mon, Jan 25, 2016 at 4:12 PM, David Jones 
>> wrote:
>>
>>> This is a known problem with 3.7.1.
>>>
>>> It should be fixed for 3.8. You should be able to try out 3.8rc1 right
>>> now.
>>>
>>>
>>>
>>> On Mon, Jan 25, 2016 at 5:37 PM, Jeffrey Tan via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 Hi,

 My colleague downloaded and built 3.7.1 version of lldb on Linux. When
 we used it to attach to a normal process(like sleep), it just hangs 
 forever:

 bin/lldb -n sleep
 (lldb) process attach --name "sleep"

 And my private built 3.8.0 version works fine.

 Just to confirm, is 3.7.1 a bad version? Is there any known issue about
 it?

 Thanks

 ___
 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] something just toasted the test suite on OS X

[Todd Fiala via lldb-dev]

Not sure exactly what it is, but all the tests are failing due to some bad
assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.

I am not going to be able to look at details on that, but here's a link to
the log on the OS X builder:

http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console

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

Re: [lldb-dev] something just toasted the test suite on OS X

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev 
>  wrote:
> 
> Not sure exactly what it is, but all the tests are failing due to some bad 
> assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.
> 

Author: zturner
Date: Mon Jan 25 18:59:42 2016
New Revision: 258759

URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev 

Log:
Write the session log file in UTF-8.

Previously we were writing in the default encoding, which depends
on the operating system and is not guaranteed to be unicode aware.
On Python 3, this would lead to a situation where writing unicode
text to the log file generates an exception.  The fix here is to
write session logs using the proper encoding, which incidentally
fixes another test, so xfail is removed from that.

sounds like a likely culprit from what you’re saying

> I am not going to be able to look at details on that, but here's a link to 
> the log on the OS X builder:
> 

Do you want me to revert?

> http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console 
> 
> 
> -- 
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [lldb-dev] something just toasted the test suite on OS X

[Todd Fiala via lldb-dev]

Well our whole test suite just stopped running, so yes.

On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata  wrote:

>
> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Not sure exactly what it is, but all the tests are failing due to some bad
> assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.
>
>
> Author: zturner
> Date: Mon Jan 25 18:59:42 2016
> New Revision: 258759
>
> URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
> Log:
> Write the session log file in UTF-8.
>
> Previously we were writing in the default encoding, which depends
> on the operating system and is not guaranteed to be unicode aware.
> On Python 3, this would lead to a situation where writing unicode
> text to the log file generates an exception.  The fix here is to
> write session logs using the proper encoding, which incidentally
> fixes another test, so xfail is removed from that.
>
> sounds like a likely culprit from what you’re saying
>
> I am not going to be able to look at details on that, but here's a link to
> the log on the OS X builder:
>
>
> Do you want me to revert?
>
> http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console
>
> --
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>


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

Re: [lldb-dev] something just toasted the test suite on OS X

[Todd Fiala via lldb-dev]

I think I see what happened w/r/t why no emails when out when the build
went heavy red.  (Well they went out internally, but not externally).  When
I made the change on Friday to improve the workflow for the Green Dragon OS
X builder and test output, I switched email over to the builder step, which
doesn't know anything about who made which changes.  So it didn't know who
to put on the blame list for the broken build.  Drats, I'll have to figure
that out.

I'd really prefer to have all those stages happening in one build step to
keep it clear what's going on.

On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala  wrote:

> Well our whole test suite just stopped running, so yes.
>
> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
> wrote:
>
>>
>> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Not sure exactly what it is, but all the tests are failing due to some
>> bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.
>>
>>
>> Author: zturner
>> Date: Mon Jan 25 18:59:42 2016
>> New Revision: 258759
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
>> Log:
>> Write the session log file in UTF-8.
>>
>> Previously we were writing in the default encoding, which depends
>> on the operating system and is not guaranteed to be unicode aware.
>> On Python 3, this would lead to a situation where writing unicode
>> text to the log file generates an exception.  The fix here is to
>> write session logs using the proper encoding, which incidentally
>> fixes another test, so xfail is removed from that.
>>
>> sounds like a likely culprit from what you’re saying
>>
>> I am not going to be able to look at details on that, but here's a link
>> to the log on the OS X builder:
>>
>>
>> Do you want me to revert?
>>
>> http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console
>>
>> --
>> -Todd
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>> Thanks,
>> *- Enrico*
>> 📩 egranata@.com ☎️ 27683
>>
>>
>
>
> --
> -Todd
>



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

Re: [lldb-dev] something just toasted the test suite on OS X

[Zachary Turner via lldb-dev]

sorry, yea I stuck around for a while after that patch waiting for emails,
but nothing came through.  Please revert in the meantime, I'll work on a
fix tomorrow.

On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I think I see what happened w/r/t why no emails when out when the build
> went heavy red.  (Well they went out internally, but not externally).  When
> I made the change on Friday to improve the workflow for the Green Dragon OS
> X builder and test output, I switched email over to the builder step, which
> doesn't know anything about who made which changes.  So it didn't know who
> to put on the blame list for the broken build.  Drats, I'll have to figure
> that out.
>
> I'd really prefer to have all those stages happening in one build step to
> keep it clear what's going on.
>
> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala  wrote:
>
>> Well our whole test suite just stopped running, so yes.
>>
>> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
>> wrote:
>>
>>>
>>> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Not sure exactly what it is, but all the tests are failing due to some
>>> bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.
>>>
>>>
>>> Author: zturner
>>> Date: Mon Jan 25 18:59:42 2016
>>> New Revision: 258759
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
>>> Log:
>>> Write the session log file in UTF-8.
>>>
>>> Previously we were writing in the default encoding, which depends
>>> on the operating system and is not guaranteed to be unicode aware.
>>> On Python 3, this would lead to a situation where writing unicode
>>> text to the log file generates an exception.  The fix here is to
>>> write session logs using the proper encoding, which incidentally
>>> fixes another test, so xfail is removed from that.
>>>
>>> sounds like a likely culprit from what you’re saying
>>>
>>> I am not going to be able to look at details on that, but here's a link
>>> to the log on the OS X builder:
>>>
>>>
>>> Do you want me to revert?
>>>
>>> http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console
>>>
>>> --
>>> -Todd
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>>
>>> Thanks,
>>> *- Enrico*
>>> 📩 egranata@.com ☎️ 27683
>>>
>>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
> ___
> 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] something just toasted the test suite on OS X

[Todd Fiala via lldb-dev]

Oh no worries, I borked the builder email on our currently cumbersome
multi-step process.

They're failing with a permutation of this:

Traceback (most recent call last):
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2224, in dsym_test_method
return attrvalue(self)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 561, in wrapper
return func(self, *args, **kwargs)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py",
line 31, in test_inferior_abort_received_debugserver
self.init_debugserver_test()
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py",
line 199, in init_debugserver_test
(self.named_pipe_path, self.named_pipe, self.named_pipe_fd) =
self.create_named_pipe()
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py",
line 125, in create_named_pipe
self.addTearDownHook(shutdown_named_pipe)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1589, in addTearDownHook
print("Adding tearDown hook:", getsource_if_available(hook), file=sbuf)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 265, in __exit__
print(self.getvalue(), file=self.session)
TypeError: must be unicode, not str
Config=x86_64-/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
Traceback (most recent call last):
  File "/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/test/dotest.py",
line 7, in 
lldbsuite.test.run_suite()
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/dotest.py",
line 1089, in run_suite
resultclass=test_result.LLDBTestResult).run(configuration.suite)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/third_party/Python/module/unittest2/unittest2/runner.py",
line 162, in run
test(result)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
line 65, in __call__
return self.run(*args, **kwds)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
line 85, in run
self._wrapped_run(result)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
line 115, in _wrapped_run
test._wrapped_run(result, debug)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
line 117, in _wrapped_run
test(result)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/third_party/Python/module/unittest2/unittest2/case.py",
line 433, in __call__
return self.run(*args, **kwds)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/third_party/Python/module/unittest2/unittest2/case.py",
line 361, in run
success = self.runMethod(testMethod, result)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/third_party/Python/module/unittest2/unittest2/case.py",
line 413, in runMethod
result.addError(self, sys.exc_info())
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/test_result.py",
line 148, in addError
method()
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1666, in markError
print("ERROR", file=sbuf)
  File 
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 265, in __exit__
print(self.getvalue(), file=self.session)
TypeError: must be unicode, not str



There's a pattern for using a call that guarantees contents are
converted to either (say) Unicode or Bytes, where the right way to do
it depends on Python 2 or Python 3.  I see that this isn't causing a
problem on the Linux builder, which is a bit puzzling unless they are
using Python 3.  (Or something else is going on that isn't obvious).


I think I may leave it as is and try to fix it.  If I can't figure it
out quickly-ish tonight, I will revert and we can figure out the right
fix tomorrow.  (i.e. I'm not going to revert it right away if I can
fix it quickly).


-Todd


On Mon, Jan 25, 2016 at 8:54 PM, Zachary Turner  wrote:

> sorry, yea I stuck around for a while after that patch waiting for emails,
> but nothing came through.  Please revert in the meantime, I'll work on a
> fix tomorrow.
>
> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I think I see what happened w/r/t why no emails when out when the build
>> went heavy red.  (Well they went out internally, but not externally).  When
>> I 

Re: [lldb-dev] something just toasted the test suite on OS X

[Enrico Granata via lldb-dev]

Should be reverted in 258791.

Sent from my iPhone

> On Jan 25, 2016, at 8:54 PM, Zachary Turner  wrote:
> 
> sorry, yea I stuck around for a while after that patch waiting for emails, 
> but nothing came through.  Please revert in the meantime, I'll work on a fix 
> tomorrow.
> 
>> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev 
>>  wrote:
>> I think I see what happened w/r/t why no emails when out when the build went 
>> heavy red.  (Well they went out internally, but not externally).  When I 
>> made the change on Friday to improve the workflow for the Green Dragon OS X 
>> builder and test output, I switched email over to the builder step, which 
>> doesn't know anything about who made which changes.  So it didn't know who 
>> to put on the blame list for the broken build.  Drats, I'll have to figure 
>> that out.
>> 
>> I'd really prefer to have all those stages happening in one build step to 
>> keep it clear what's going on.
>> 
>>> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala  wrote:
>>> Well our whole test suite just stopped running, so yes.
>>> 
 On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata  wrote:
 
> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev 
>  wrote:
> 
> Not sure exactly what it is, but all the tests are failing due to some 
> bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.
 
 Author: zturner
 Date: Mon Jan 25 18:59:42 2016
 New Revision: 258759
 
 URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
 Log:
 Write the session log file in UTF-8.
 
 Previously we were writing in the default encoding, which depends
 on the operating system and is not guaranteed to be unicode aware.
 On Python 3, this would lead to a situation where writing unicode
 text to the log file generates an exception.  The fix here is to
 write session logs using the proper encoding, which incidentally
 fixes another test, so xfail is removed from that.
 
 sounds like a likely culprit from what you’re saying
 
> I am not going to be able to look at details on that, but here's a link 
> to the log on the OS X builder:
 
 Do you want me to revert?
 
> http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console
> 
> -- 
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
 
 
 Thanks,
 - Enrico
 📩 egranata@.com ☎️ 27683
>>> 
>>> 
>>> 
>>> -- 
>>> -Todd
>> 
>> 
>> 
>> -- 
>> -Todd
>> ___
>> 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] something just toasted the test suite on OS X

[Todd Fiala via lldb-dev]

Hah the comedy of late night emails.  We all go away for hours, then all
get back here within minutes :-)

(Zachary - I will still have a look at it tonight since I am curious why we
weren't seeing it on all the (what I think are) Python 2.7-based systems).

On Mon, Jan 25, 2016 at 9:02 PM, Enrico Granata  wrote:

> Should be reverted in 258791.
>
> Sent from my iPhone
>
> On Jan 25, 2016, at 8:54 PM, Zachary Turner  wrote:
>
> sorry, yea I stuck around for a while after that patch waiting for emails,
> but nothing came through.  Please revert in the meantime, I'll work on a
> fix tomorrow.
>
> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I think I see what happened w/r/t why no emails when out when the build
>> went heavy red.  (Well they went out internally, but not externally).  When
>> I made the change on Friday to improve the workflow for the Green Dragon OS
>> X builder and test output, I switched email over to the builder step, which
>> doesn't know anything about who made which changes.  So it didn't know who
>> to put on the blame list for the broken build.  Drats, I'll have to figure
>> that out.
>>
>> I'd really prefer to have all those stages happening in one build step to
>> keep it clear what's going on.
>>
>> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala  wrote:
>>
>>> Well our whole test suite just stopped running, so yes.
>>>
>>> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
>>> wrote:
>>>

 On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

 Not sure exactly what it is, but all the tests are failing due to some
 bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.


 Author: zturner
 Date: Mon Jan 25 18:59:42 2016
 New Revision: 258759

 URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
 Log:
 Write the session log file in UTF-8.

 Previously we were writing in the default encoding, which depends
 on the operating system and is not guaranteed to be unicode aware.
 On Python 3, this would lead to a situation where writing unicode
 text to the log file generates an exception.  The fix here is to
 write session logs using the proper encoding, which incidentally
 fixes another test, so xfail is removed from that.

 sounds like a likely culprit from what you’re saying

 I am not going to be able to look at details on that, but here's a link
 to the log on the OS X builder:


 Do you want me to revert?

 http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console

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



 Thanks,
 *- Enrico*
 📩 egranata@.com ☎️ 27683


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


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

Re: [lldb-dev] something just toasted the test suite on OS X

[Zachary Turner via lldb-dev]

I'm also not sure why Linux isn't failing.  Looking at the documentation
for io.write https://docs.python.org/2/library/io.html#text-i-o>
object, i see this:

write(*s*) 

Write the unicode 
 string *s* to the stream and return the number of characters written.
So clearly it does have to be a unicode object, and saying
print(self.getvalue(), file=self.session) is clearly NOT printing a unicode
string to the file.

What's the pattern you're referring to?  You can't convert a string to a
unicode without specifying an encoding, and it seems annoying to have to do
that on every single call to print.

On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner  wrote:

> sorry, yea I stuck around for a while after that patch waiting for emails,
> but nothing came through.  Please revert in the meantime, I'll work on a
> fix tomorrow.
>
> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I think I see what happened w/r/t why no emails when out when the build
>> went heavy red.  (Well they went out internally, but not externally).  When
>> I made the change on Friday to improve the workflow for the Green Dragon OS
>> X builder and test output, I switched email over to the builder step, which
>> doesn't know anything about who made which changes.  So it didn't know who
>> to put on the blame list for the broken build.  Drats, I'll have to figure
>> that out.
>>
>> I'd really prefer to have all those stages happening in one build step to
>> keep it clear what's going on.
>>
>> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala  wrote:
>>
>>> Well our whole test suite just stopped running, so yes.
>>>
>>> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
>>> wrote:
>>>

 On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

 Not sure exactly what it is, but all the tests are failing due to some
 bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.


 Author: zturner
 Date: Mon Jan 25 18:59:42 2016
 New Revision: 258759

 URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
 Log:
 Write the session log file in UTF-8.

 Previously we were writing in the default encoding, which depends
 on the operating system and is not guaranteed to be unicode aware.
 On Python 3, this would lead to a situation where writing unicode
 text to the log file generates an exception.  The fix here is to
 write session logs using the proper encoding, which incidentally
 fixes another test, so xfail is removed from that.

 sounds like a likely culprit from what you’re saying

 I am not going to be able to look at details on that, but here's a link
 to the log on the OS X builder:


 Do you want me to revert?

 http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console

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



 Thanks,
 *- Enrico*
 📩 egranata@.com ☎️ 27683


>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>> ___
>> 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] something just toasted the test suite on OS X

[Todd Fiala via lldb-dev]

It's in item 3 from Effective Python, by Brett Slatkin, which goes over
having methods that always go to unicode or to byte streams taking either
unicode or byte style strings, for both Python 2 and Python 3.  Essentially
you figure out what you want it to be in, and you write a couple helper
routes to go in either the "to unicode" or the "to bytes" direction.  It
basically looks at the type of the string/bytes you give it, and makes sure
it becomes what you need.  It's going to assume an encoding like utf-8.

On Mon, Jan 25, 2016 at 9:09 PM, Zachary Turner  wrote:

> I'm also not sure why Linux isn't failing.  Looking at the documentation
> for io.write object, i see this:
>
> write(*s*) 
>
> Write the unicode
>  string *s* to
> the stream and return the number of characters written.
> So clearly it does have to be a unicode object, and saying
> print(self.getvalue(), file=self.session) is clearly NOT printing a unicode
> string to the file.
>
> What's the pattern you're referring to?  You can't convert a string to a
> unicode without specifying an encoding, and it seems annoying to have to do
> that on every single call to print.
>
> On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner  wrote:
>
>> sorry, yea I stuck around for a while after that patch waiting for
>> emails, but nothing came through.  Please revert in the meantime, I'll work
>> on a fix tomorrow.
>>
>> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> I think I see what happened w/r/t why no emails when out when the build
>>> went heavy red.  (Well they went out internally, but not externally).  When
>>> I made the change on Friday to improve the workflow for the Green Dragon OS
>>> X builder and test output, I switched email over to the builder step, which
>>> doesn't know anything about who made which changes.  So it didn't know who
>>> to put on the blame list for the broken build.  Drats, I'll have to figure
>>> that out.
>>>
>>> I'd really prefer to have all those stages happening in one build step
>>> to keep it clear what's going on.
>>>
>>> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala 
>>> wrote:
>>>
 Well our whole test suite just stopped running, so yes.

 On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
 wrote:

>
> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Not sure exactly what it is, but all the tests are failing due to some
> bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.
>
>
> Author: zturner
> Date: Mon Jan 25 18:59:42 2016
> New Revision: 258759
>
> URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
> Log:
> Write the session log file in UTF-8.
>
> Previously we were writing in the default encoding, which depends
> on the operating system and is not guaranteed to be unicode aware.
> On Python 3, this would lead to a situation where writing unicode
> text to the log file generates an exception.  The fix here is to
> write session logs using the proper encoding, which incidentally
> fixes another test, so xfail is removed from that.
>
> sounds like a likely culprit from what you’re saying
>
> I am not going to be able to look at details on that, but here's a
> link to the log on the OS X builder:
>
>
> Do you want me to revert?
>
> http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console
>
> --
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>


 --
 -Todd

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


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

Re: [lldb-dev] something just toasted the test suite on OS X

[Todd Fiala via lldb-dev]

Okay we're back to green here:
http://lab.llvm.org:8080/green/job/lldb_build_test/16173/

Thanks, Enrico!

Zachary, I may let this rest until the morning.  If you want to try
something else, shoot me a patch and I'll gladly try it.

-Todd

On Mon, Jan 25, 2016 at 9:16 PM, Todd Fiala  wrote:

> It's in item 3 from Effective Python, by Brett Slatkin, which goes over
> having methods that always go to unicode or to byte streams taking either
> unicode or byte style strings, for both Python 2 and Python 3.  Essentially
> you figure out what you want it to be in, and you write a couple helper
> routes to go in either the "to unicode" or the "to bytes" direction.  It
> basically looks at the type of the string/bytes you give it, and makes sure
> it becomes what you need.  It's going to assume an encoding like utf-8.
>
> On Mon, Jan 25, 2016 at 9:09 PM, Zachary Turner 
> wrote:
>
>> I'm also not sure why Linux isn't failing.  Looking at the documentation
>> for io.write object, i see this:
>>
>> write(*s*)
>> 
>>
>> Write the unicode
>>  string *s* to
>> the stream and return the number of characters written.
>> So clearly it does have to be a unicode object, and saying
>> print(self.getvalue(), file=self.session) is clearly NOT printing a unicode
>> string to the file.
>>
>> What's the pattern you're referring to?  You can't convert a string to a
>> unicode without specifying an encoding, and it seems annoying to have to do
>> that on every single call to print.
>>
>> On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner 
>> wrote:
>>
>>> sorry, yea I stuck around for a while after that patch waiting for
>>> emails, but nothing came through.  Please revert in the meantime, I'll work
>>> on a fix tomorrow.
>>>
>>> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 I think I see what happened w/r/t why no emails when out when the build
 went heavy red.  (Well they went out internally, but not externally).  When
 I made the change on Friday to improve the workflow for the Green Dragon OS
 X builder and test output, I switched email over to the builder step, which
 doesn't know anything about who made which changes.  So it didn't know who
 to put on the blame list for the broken build.  Drats, I'll have to figure
 that out.

 I'd really prefer to have all those stages happening in one build step
 to keep it clear what's going on.

 On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala 
 wrote:

> Well our whole test suite just stopped running, so yes.
>
> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
> wrote:
>
>>
>> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Not sure exactly what it is, but all the tests are failing due to
>> some bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to 
>> guess.
>>
>>
>> Author: zturner
>> Date: Mon Jan 25 18:59:42 2016
>> New Revision: 258759
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
>> Log:
>> Write the session log file in UTF-8.
>>
>> Previously we were writing in the default encoding, which depends
>> on the operating system and is not guaranteed to be unicode aware.
>> On Python 3, this would lead to a situation where writing unicode
>> text to the log file generates an exception.  The fix here is to
>> write session logs using the proper encoding, which incidentally
>> fixes another test, so xfail is removed from that.
>>
>> sounds like a likely culprit from what you’re saying
>>
>> I am not going to be able to look at details on that, but here's a
>> link to the log on the OS X builder:
>>
>>
>> Do you want me to revert?
>>
>> http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console
>>
>> --
>> -Todd
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>> Thanks,
>> *- Enrico*
>> 📩 egranata@.com ☎️ 27683
>>
>>
>
>
> --
> -Todd
>



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

>>>
>
>
> --
> -Todd
>



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