search for: null_deref

...f the address sanitizer regression >> tests for a PPC64 target (Power7 machine). My understanding is that most of >> the failures are related with the fact the stack is not being dumped. >> >> I tried to understand what might be wrong and started by looking into the >> null_deref.cc test as it hangs during the test run. I observe that after >> the detection of the faulty memory access it receives a SEGV after entering >> ReportSIGSEGV() more precisely when it gets to the __intercept_strlen() and >> tries to access flags()->replace_str. The caller of _...

...all, I have been experiencing the failure of the address sanitizer regression tests for a PPC64 target (Power7 machine). My understanding is that most of the failures are related with the fact the stack is not being dumped. I tried to understand what might be wrong and started by looking into the null_deref.cc test as it hangs during the test run. I observe that after the detection of the faulty memory access it receives a SEGV after entering ReportSIGSEGV() more precisely when it gets to the __intercept_strlen() and tries to access flags()->replace_str. The caller of __intercept_strlen() is get_...

On Mon, 2014-09-08 at 22:00 -0400, Samuel F Antao wrote: > Alexey, Alexander, > > Thanks for the suggestions. I tried removing the flag SA_NODEFER but > it didn't do any good... I have been digging into the problem with the > null_deref test today but I was unable to clearly identify the > problem. I suspect that it was either a bug with the calling > convention/unwinding that lead to the flags() pointer to get > corrupted. It is also possible that it was related with endianess > issues caused by some bug in the pointe...

On Mon, Sep 8, 2014 at 7:00 PM, Samuel F Antao <sfantao at us.ibm.com> wrote: > Alexey, Alexander, > > Thanks for the suggestions. I tried removing the flag SA_NODEFER but it > didn't do any good... I have been digging into the problem with the > null_deref test today but I was unable to clearly identify the problem. I > suspect that it was either a bug with the calling convention/unwinding that > lead to the flags() pointer to get corrupted. It is also possible that it > was related with endianess issues caused by some bug in the pointer &gt...

Dear testers, 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. I'll upload sources, docs, and your binaries to the pre-release website once they're ready. Thanks, Hans

...zer-i386-freebsd :: TestCases/invalid-free.cc (3195 of 38616) > FAIL: AddressSanitizer-i386-freebsd :: TestCases/invalid-pointer-pairs.cc (3197 of 38616) > FAIL: AddressSanitizer-i386-freebsd :: TestCases/large_func_test.cc (3198 of 38616) > FAIL: AddressSanitizer-i386-freebsd :: TestCases/null_deref.cc (3209 of 38616) > FAIL: AddressSanitizer-i386-freebsd :: TestCases/partial_right.cc (3211 of 38616) > FAIL: AddressSanitizer-i386-freebsd :: TestCases/print_summary.cc (3214 of 38616) > FAIL: AddressSanitizer-i386-freebsd :: TestCases/sanity_check_pure_c.c (3224 of 38616) > FAIL: Add...

Hi, The 6.0.1-rc2 release has been tagged. Testers may begin testing and reporting results. -Tom

Hi, I've just tagged the 6.0.1-rc1 release. Testers may begin testing and uploading binaries. Also, any tester who has not tested 5.0.2-rc1 and would like to do so please try to do this before Friday, because I would like to tag 5.0.2-final then. As a reminder to users and developers, May 18 is the deadline for submitting merge requests for 6.0.1, so there is still time to get bug fixes

Bill, For some reason the llvm-symbolizer tests fail on ppc: http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/182/steps/ninja%20check%201/logs/stdio because it can't be started: /home/buildbots/ppc64le-clang-test/clang-ppc64le/stage1/./bin/llvm-symbolizer: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by

...-pairs-subtract-errors.cc AddressSanitizer-i386-freebsd :: TestCases/invalid-pointer-pairs-subtract-success.cc AddressSanitizer-i386-freebsd :: TestCases/invalid-pointer-pairs.cc AddressSanitizer-i386-freebsd :: TestCases/large_func_test.cc AddressSanitizer-i386-freebsd :: TestCases/null_deref.cc AddressSanitizer-i386-freebsd :: TestCases/partial_right.cc AddressSanitizer-i386-freebsd :: TestCases/print_summary.cc AddressSanitizer-i386-freebsd :: TestCases/sanity_check_pure_c.c AddressSanitizer-i386-freebsd :: TestCases/stack-buffer-overflow.cc AddressSanitizer-i386-f...

On Thu, Feb 8, 2018 at 10:43 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> There's been a lot of merges since rc1, and hopefully the tests are in >> a better state now. >> >> 6.0.0-rc2 was just tagged, after r324506. >> >>

On 31 Jul 2017, at 19:26, Hans Wennborg <hans at chromium.org> wrote: > > On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric <dimitry at andric.com> wrote: >> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev <cfe-dev at lists.llvm.org> wrote: >>> >>> 5.0.0-rc1 has just been tagged. >>> >>> Please build, test and upload binaries