Re: [lldb-dev] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged
> -Original Message- > From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf > Of Hans Wennborg > Sent: 04 August 2017 00:52 > To: Simon Dardis > Cc: Release-testers; llvm-dev; cfe-dev; openmp-dev (openmp- > d...@lists.llvm.org); LLDB Dev > Subject: Re: [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged > > On Tue, Aug 1, 2017 at 9:13 AM, Hans Wennborg > wrote: > > On Tue, Aug 1, 2017 at 3:01 AM, Simon Dardis > wrote: > >> Currently I'm getting "Couldn't write to remote file > >> "/home/testers/uploads/clang+llvm-5.0.0-rc1-mips-linux-gnu.tar.xz": > Failure", does that account need more space? > > > > Yes, the partition is full. I've asked Anton to see if we can fix this. > > Tanya created a new directory on the server: /data/testers-uploads/ Can you > try uploading to that instead? Uploaded, thanks. Hashes: SHA1(clang+llvm-5.0.0-rc1-mips-linux-gnu.tar.xz)= ef27e42baa25460edd3ceb2207e93a9a1d0f504e SHA1(clang+llvm-5.0.0-rc1-mipsel-linux-gnu.tar.xz)= 84b5c5e38e7d7e14af3f5482125a56172eeabd20 SHA1(clang+llvm-5.0.0-rc1-x86_64-linux-gnu-debian8.tar.xz)= dede2aa20b591c878794587fdea22369bbc00516 Thanks, Simon ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged
On 31 Jul 2017, at 20:13, Dimitry Andric via Release-testers
wrote:
>
> On 31 Jul 2017, at 19:26, Hans Wennborg wrote:
>>
>> On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric wrote:
>>> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev
>>> wrote:
5.0.0-rc1 has just been tagged.
Please build, test and upload binaries to the sftp. Let me know if
there are any issues.
>>>
>>> Built and tested rc1. Test failures on amd64-freebsd10:
>>>
>>> FAIL: LLVM-Unit ::
>>> ExecutionEngine/Orc/./OrcJITTests/DummyRPC.TestClearHandlers (1346 of 38616)
>>> FAIL: AddressSanitizer-Unit ::
>>> ./Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest (2480 of 38616)
>>> FAIL: AddressSanitizer-Unit ::
>>> ./Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2505 of
>>> 38616)
>>> FAIL: AddressSanitizer-Unit ::
>>> ./Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest (2542 of
>>> 38616)
>>> FAIL: AddressSanitizer-Unit ::
>>> ./Asan-i386-inline-Test/AddressSanitizer.WrongFreeTest (2546 of 38616)
> ...
>> Do we know what's up with all of these ASan failures? Is there a bug for it?
>
> I spent a limited amount of debugging on it, but the common problem is that
> on i386 (aka 32-bit x86) all programs compiled with -fsanitize=address now
> die with:
>
> ==11122==AddressSanitizer CHECK failed:
> /usr/src/contrib/compiler-rt/lib/asan/asan_poisoning.cc:36
> "((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
...
> I know that it *did* work at some point in the past, but it got broken in
> recent history. I will have to do some archeology to figure out what
> happened.
>
> Does anybody know whether the shadow granularity was different at some point?
Ok, some further research showed that I have been conflating two different
issues here.
The first issue is that FreeBSD 12-CURRENT recently received an update to
jemalloc, our default memory allocator, in
https://reviews.freebsd.org/rS319971. For some reason, this causes an
alignment problem now when ASan is initializing. E.g. exactly the same ASan
test case works as expected on FreeBSD 10 and 11, but on 12 it results in:
==22338==AddressSanitizer CHECK failed:
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_poisoning.cc:36
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
#0 0x80b5960 in __asan::AsanCheckFailed(char const*, int, char const,
unsigned long long, unsigned long long)
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_rtl.cc:69:3
#1 0x80c754a in __sanitizer::CheckFailed(char const*, int, char const,
unsigned long long, unsigned long long)
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79:5
#2 0x80af5e8 in __asan::PoisonShadow(unsigned long, unsigned long,
unsigned char)
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_poisoning.cc:36:3
#3 0x80b74e7 in ClearShadowForThreadStackAndTLS
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_thread.cc:285:5
#4 0x80b74e7 in __asan::AsanThread::Init(void)
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_thread.cc:232
#5 0x80b768d in __asan::AsanThread::ThreadStart(unsigned long,
__sanitizer::atomic_uintptr_t*)
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_thread.cc:241:3
#6 0x80b55dc in __asan::AsanInitInternal(void)
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_rtl.cc:591:16
#7 0x807a648 in clock_gettime
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1882:3
While this is pretty unfortunate, it is not really a problem with the 5.0.0
release, since it also happens with ASan-instrumented executables compiled by
earlier versions of clang.
The other issue, which I encountered while building 5.0.0 rc1 on FreeBSD 10, is
in compiler-rt itself. It's apparently being caused by
https://reviews.llvm.org/rL305058 ("Fix ASan internal failure in
AllocateFromLocalPool"), meant to address PR 33206. Before this commit, on
FreeBSD 10, I got just two ASan-related failures (both of which are pretty old,
I think):
Failing Tests (5):
AddressSanitizer-i386-freebsd :: TestCases/Posix/asan-sigbus.cpp
AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
LLVM :: Bindings/Go/go.test
LLVM :: DebugInfo/PDB/pdbdump-debug-subsections.test
LLVM :: tools/llvm-objdump/X86/macho-literals.test
After r305058, that ballooned to 55 ASan-related failures:
Failing Tests (58):
AddressSanitizer-Unit ::
Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest
AddressSanitizer-Unit ::
Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest
AddressSanitizer-Unit ::
Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest
Re: [lldb-dev] LLDB: Sanitizing the debugger's runtime
On 03.07.2017 18:41, Kamil Rytarowski wrote: > On 06.06.2017 17:47, Kamil Rytarowski wrote: >> Hello, >> > > Hello, > > Short update. > >> I posted the LLDB/NetBSD report for May: >> >> https://blog.netbsd.org/tnf/entry/lldb_sanitizing_the_debugger_s >> >> I'm heading now to get the LLVM sanitizers aboard and use them for >> further development of the LLDB/NetBSD port. >> >> I need to modify the whole stack of LLVM (llvm, clang, compiler-rt, >> libsanitizer). I prepared environment to execute tests in LLVM and Clang >> and they appear to be in acceptable shape now to move on to sanitizers. >> > > LLVM asan and ubsan on NetBSD > http://blog.netbsd.org/tnf/entry/llvm_asan_and_ubsan_on > > Roadmap for the next month: > - Send upstream LLVM asan and ubsan support. > - Correct more problems triggered by LLVM and Clang test-suites. > - Resume msan and tsan porting. > http://blog.netbsd.org/tnf/entry/llvm_clang_and_compiler_rt I will continue during August the same tasks. signature.asc Description: OpenPGP digital signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged
I've uploaded the x86_64/Darwin package: SHA1(clang+llvm-5.0.0-rc1-x86_64-apple-darwin.tar.xz) = 66cb113cb735b7f0d3b7eebe155969f069c8a684 SHA256(clang+llvm-5.0.0-rc1-x86_64-apple-darwin.tar.xz) = ca13407528536f0c4e9b5bf00115a2f3d65d73f512737d334f69ad53bd18101c thanks! vedant > On Aug 3, 2017, at 4:51 PM, Hans Wennborg via Release-testers > wrote: > > On Tue, Aug 1, 2017 at 9:13 AM, Hans Wennborg wrote: >> On Tue, Aug 1, 2017 at 3:01 AM, Simon Dardis wrote: >>> Currently I'm getting "Couldn't write to remote file >>> "/home/testers/uploads/clang+llvm-5.0.0-rc1-mips-linux-gnu.tar.xz": >>> Failure", >>> does that account need more space? >> >> Yes, the partition is full. I've asked Anton to see if we can fix this. > > Tanya created a new directory on the server: /data/testers-uploads/ > Can you try uploading to that instead? > ___ > Release-testers mailing list > release-test...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged
On Fri, Aug 4, 2017 at 2:33 AM, Simon Dardis wrote: > > >> -Original Message- >> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf >> Of Hans Wennborg >> Sent: 04 August 2017 00:52 >> To: Simon Dardis >> Cc: Release-testers; llvm-dev; cfe-dev; openmp-dev (openmp- >> d...@lists.llvm.org); LLDB Dev >> Subject: Re: [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged >> >> On Tue, Aug 1, 2017 at 9:13 AM, Hans Wennborg >> wrote: >> > On Tue, Aug 1, 2017 at 3:01 AM, Simon Dardis >> wrote: >> >> Currently I'm getting "Couldn't write to remote file >> >> "/home/testers/uploads/clang+llvm-5.0.0-rc1-mips-linux-gnu.tar.xz": >> Failure", does that account need more space? >> > >> > Yes, the partition is full. I've asked Anton to see if we can fix this. >> >> Tanya created a new directory on the server: /data/testers-uploads/ Can you >> try uploading to that instead? > > Uploaded, thanks. > > Hashes: > SHA1(clang+llvm-5.0.0-rc1-mips-linux-gnu.tar.xz)= > ef27e42baa25460edd3ceb2207e93a9a1d0f504e > SHA1(clang+llvm-5.0.0-rc1-mipsel-linux-gnu.tar.xz)= > 84b5c5e38e7d7e14af3f5482125a56172eeabd20 > SHA1(clang+llvm-5.0.0-rc1-x86_64-linux-gnu-debian8.tar.xz)= > dede2aa20b591c878794587fdea22369bbc00516 Thanks! I've added them to the pre-release page. Cheers, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged
On Fri, Aug 4, 2017 at 10:39 AM, Vedant Kumar wrote: > I've uploaded the x86_64/Darwin package: > > SHA1(clang+llvm-5.0.0-rc1-x86_64-apple-darwin.tar.xz) = > 66cb113cb735b7f0d3b7eebe155969f069c8a684 > SHA256(clang+llvm-5.0.0-rc1-x86_64-apple-darwin.tar.xz) = > ca13407528536f0c4e9b5bf00115a2f3d65d73f512737d334f69ad53bd18101c Thanks! I've added them to the pre-release page. Cheers, Hans >> On Aug 3, 2017, at 4:51 PM, Hans Wennborg via Release-testers >> wrote: >> >> On Tue, Aug 1, 2017 at 9:13 AM, Hans Wennborg wrote: >>> On Tue, Aug 1, 2017 at 3:01 AM, Simon Dardis >>> wrote: Currently I'm getting "Couldn't write to remote file "/home/testers/uploads/clang+llvm-5.0.0-rc1-mips-linux-gnu.tar.xz": Failure", does that account need more space? >>> >>> Yes, the partition is full. I've asked Anton to see if we can fix this. >> >> Tanya created a new directory on the server: /data/testers-uploads/ >> Can you try uploading to that instead? >> ___ >> Release-testers mailing list >> release-test...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Remote debugging ARM target from x86 host
Hi, I am trying to remote debug ARM (linux) target from x86 (linux) host and I am getting the following error while trying to launch a process. The local debugging on ARM works. error: connect remote failed (invalid host:port specification: '10.10.2.3') error: process launch failed: invalid host:port specification: '10.10.2.3' It appears the above error is because the gdb-remote is returning the communication port as zero. < 36> send packet: $qLaunchGDBServer;host:svrlin249;#bb < 19> read packet: $pid:298;port:0;#bf What are the possible reasons for the above behavior from gdb-remote and how I could resolve this? If it helps, below is the full log. (lldb) log enable lldb comm (lldb) log enable gdb-remote packets (lldb) platform select remote-linux Platform: remote-linux Connected: no (lldb) platform connect connect://10.10.2.3:500 0x915bd78 Communication::Communication (name = gdb-remote.client) 0x915bd78 Communication::Disconnect () 0x915bd78 Communication::Disconnect () 0x915bd78 Communication::Connect (url = connect://10.10.2.3:500) Socket::TcpConnect (host/port = 10.10.2.3:500) TCPSocket::Connect (host/port = 10.10.2.3:500) 0x915bd78 Communication::Write (src = 0xbfcb7433, src_len = 1) connection = 0x915f578 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb7433, src_len = 1, flags = 0) => 1 (error = (null)) < 1> send packet: + this = 0x0915BD78, dst = 0xBFCB53EC, dst_len = 8192, timeout = 1 us, connection = 0x0915F578 0x915bd78 Communication::Write (src = 0x916022c, src_len = 19) connection = 0x915f578 0x915f608 Socket::Write() (socket = 7, src = 0x916022c, src_len = 19, flags = 0) => 19 (error = (null)) history[1] tid=0x7cbf < 1> send packet: + < 19> send packet: $QStartNoAckMode#b0 this = 0x0915BD78, dst = 0xBFCB51AC, dst_len = 8192, timeout = 600 us, connection = 0x0915F578 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb51ac, src_len = 7, flags = 0) => 7 (error = (null)) < 1> read packet: + < 6> read packet: $OK#9a 0x915bd78 Communication::Write (src = 0xbfcb50f3, src_len = 1) connection = 0x915f578 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb50f3, src_len = 1, flags = 0) => 1 (error = (null)) < 1> send packet: + 0x915bd78 Communication::Write (src = 0x9161ff4, src_len = 13) connection = 0x915f578 0x915f608 Socket::Write() (socket = 7, src = 0x9161ff4, src_len = 13, flags = 0) => 13 (error = (null)) < 13> send packet: $qHostInfo#9b this = 0x0915BD78, dst = 0xBFCB510C, dst_len = 8192, timeout = 100 us, connection = 0x0915F578 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb510c, src_len = 316, flags = 0) => 316 (error = (null)) < 316> read packet: $triple:61726d2d2d6c696e75782d676e75656162696866;ptrsize:4;watchpoint_exceptions_received:before;endian:little;os_version:3.10.31;os_build:332e31302e33312d6c7473692d30323836312d6738303161343066;os_kernel:233520534d5020467269204d61792031332031353a35383a3232204953542032303136;hostname:736f 63667067615f617272696135;#0a 0x915bd78 Communication::Write (src = 0x915fe9c, src_len = 18) connection = 0x915f578 0x915f608 Socket::Write() (socket = 7, src = 0x915fe9c, src_len = 18, flags = 0) => 18 (error = (null)) < 18> send packet: $qGetWorkingDir#91 this = 0x0915BD78, dst = 0xBFCB50FC, dst_len = 8192, timeout = 100 us, connection = 0x0915F578 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb50fc, src_len = 24, flags = 0) => 24 (error = (null)) < 24> read packet: $2f686f6d652f726f6f74#4b 0x915bd78 Communication::Write (src = 0x915fe9c, src_len = 19) connection = 0x915f578 0x915f608 Socket::Write() (socket = 7, src = 0x915fe9c, src_len = 19, flags = 0) => 19 (error = (null)) < 19> send packet: $qQueryGDBServer#cb this = 0x0915BD78, dst = 0xBFCB531C, dst_len = 8192, timeout = 100 us, connection = 0x0915F578 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb531c, src_len = 7, flags = 0) => 7 (error = (null)) < 7> read packet: $E04#a9 Platform: remote-linux Triple: arm-*-linux-gnueabihf OS Version: 3.10.31 (3.10.31-ltsi-02861-g801a40f) Kernel: #5 SMP Fri May 13 15:58:22 IST 2016 Hostname: socfpga_arria5 Connected: yes WorkingDir: /home/root (lldb) file main 0x915bd78 Communication::Write (src = 0x91638fc, src_len = 137) connection = 0x915f578 0x915f608 Socket::Write() (socket = 7, src = 0x91638fc, src_len = 137, flags = 0) => 137 (error = (null)) < 137> send packet: $qModuleInfo:2f686f6d652f72616d616e616e2f776f726b5f726f6f742f546f545f6c6c64622f74657374732f6d61696e;61726d2d2d6c696e75782d656162696866#f1 this = 0x0915BD78, dst = 0xBFCB172C, dst_len = 8192, timeout = 100 us, connection = 0x0915F578 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb172c, src_len = 7, flags = 0) => 7 (error = (null)) < 7> read packet: $E03#a8 Current executable set to 'main' (arm). (lldb) b main Breakpoint 1: where = main`main + 4 at main.c:4, address = 0x000104a0 (lldb) run 0x915bd78 Communication::Write (src = 0x917bae4, src_len = 36) connection = 0x915f578 0x915f608 Socket::Write() (socket = 7, src = 0x917bae4
