No build or test failures. Uploaded:
SHA256 (clang+llvm-3.7.0-rc4-i386-unknown-freebsd10.tar.xz) =
4d1cc01c701d453b5ddb64801b9014d2f902b08b6834d97878bf8feada56a8c5
SHA256 (clang+llvm-3.7.0-rc4-amd64-unknown-freebsd10.tar.xz) =
2a9feef3004e5787019ee41afc8efa7fbe84ff9621f26a083218d383f6a50802
-D
On Friday, August 28, 2015 09:46 AM, Hans Wennborg wrote:
I have promoted RC4 to final; 3.7.0 has reached its final state.
Thanks for all your hard work so far. Please build and upload binaries
with "-final", and let's ship this next week!
Uploaded: clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.
On Thu, Aug 27, 2015 at 3:01 PM, via lldb-dev
wrote:
> On Thu, Aug 27, 2015 at 05:05:23PM +, Zachary Turner via lldb-dev
> wrote:
> > Well I'm xfailing it for now, but this other method seems kind of hackish
> > to me because it means the inferior and the debugger have to coordinate
> > with
Our Ubuntu 14.10 buildbot at
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.10 is failing, and
I've been tasked to fix it because I'm the LLDB guy.
It fails with things like:
/var/lib/buildbot/slaves/hexagon-build-03/lldb-x86_64-ubuntu-14.10/llvm.obj/
Release+Asserts/lib/libclangCodeG
On Thu, Aug 27, 2015 at 6:46 PM, Hans Wennborg wrote:
> I have promoted RC4 to final; 3.7.0 has reached its final state.
>
> Thanks for all your hard work so far. Please build and upload binaries
> with "-final", and let's ship this next week!
Windows binaries uploaded. sha1sums:
44400734e1cbe1c
We've been seeing races during shutdown of inferiors for months, and I
finally tracked it down to the fact that Process holds a Target&. When an
inferior is exiting on Windows, we will get a notification of this and we
try to do various cleanup related with the target. But there are times
where t
On 28 Aug 2015, at 20:12, Hans Wennborg wrote:
>
> On Thu, Aug 27, 2015 at 6:46 PM, Hans Wennborg wrote:
>> I have promoted RC4 to final; 3.7.0 has reached its final state.
>>
>> Thanks for all your hard work so far. Please build and upload binaries
>> with "-final", and let's ship this next we
I think it should be a weak_ptr if anything. Target already holds a
shared_ptr of the process, and you will get pointer loops otherwise.
Couldn't you make sure the debug thread exits (and processes all
events) before the Target gets deleted (e.g. shut it down in
Process::Finalize() or somewhere...
We already do this in DoDestroy(), but it looks like for whatever reason
DoDestroy is not getting called on us even though the Target is being
destroyed. Or maybe it is and our DoDestroy is getting into some edge
condition that doesn't cleanup correctly. But it's hard to debug because
it only hap
