On Tue, May 3, 2016 at 10:49 AM, Konstantin Serebryany <
konstantin.s.serebry...@gmail.com> wrote:
>
>
> On Tue, May 3, 2016 at 1:03 AM, 'Ilya' via address-sanitizer <
> address-sanitizer@googlegroups.com> wrote:
>
>> Hello everybody,
>> first of all: thanks for reading. I have questions regarding
+Kuba, Anna
in case they have any ideas, or are able to reproduce it under Apple Clang.
On Thu, Jun 18, 2015 at 9:37 AM, Stefan Haller
wrote:
> I'm getting a container overflow failure that I think is a false
> positive; but I don't understand what's going on, so I'm posting here
> instead of f
On Fri, Jun 5, 2015 at 11:33 AM, Yuri Gribov wrote:
> On Fri, Jun 5, 2015 at 9:21 PM, 'Alexey Samsonov' via address-sanitizer <
> address-sanitizer@googlegroups.com> wrote:
>
>> Wow, the world of 1Tb RAM machines is here.
>> 1) You can try to allocate 1
Wow, the world of 1Tb RAM machines is here.
1) You can try to allocate 156Gb of memory with mmap() instead of malloc().
2) 64Gb is a hard limit on allocation size in ASan runtime. You can try to
bump this limit (kMaxAllowedMallocSize in lib/asan/asan_allocator.cc) and
rebuilt it from source.
On Fr
Looks like the position of Java heap (0xdfff8000) interferes with ASan
shadow memory mappings.
See memory layout in projects/compiler-rt/lib/asan/asan_mapping.h.
__asan_region_is_poisoned arguments seem to be a red herring - it's
possible that debug info is incorrect.
On Fri, Jun 5, 2015 at 5:53
Also, try "-fsanitize=address -shared-libasan", instead of passing "-lasan"
manually.
On Tue, May 26, 2015 at 3:39 PM, 'Evgeniy Stepanov' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:
> Looks like your clang installation is broken. /usr/local/bin/clang is
> 3.6.1, but the lib
Hi Konrad,
Blacklist doesn't work for disabling memory leaks. I think you should try
suppressions instead (
https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer). You can
add the following line to suppressions.txt "leak:*mylib.so", and then run
your program with LSAN_OPTIONS=suppressions
Hi,
On Wed, Apr 29, 2015 at 11:41 AM, Niel Orcutt wrote:
> I built a simple sanitized binary built with GCC 4.8.2 -fsanitize=address.
> The binary works and fails as it should. However, if I do "export
> ASAN_OPTIONS=help=1", and run the binary, the binary runs and fails in the
> same way, but
On Mon, Apr 20, 2015 at 6:39 AM, Ivan A. Kosarev
wrote:
> Thanks, Alexey. Unfortunately, editing the output won't work for tests
> where the "/proc/self/exe" is generated in place of the object file for
> symbolization purposes, like this:
>
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/Pos
Hi Ivan,
Sorry for the late response. That's unfortunate that we can't reliably get
executable name on FreeBSD... I would abstain from
adding yet another runtime flag or interface function for that purpose,
though. I'd rather fix the test to pass on FreeBSD.
For instance, if you that the name of
On Tue, Feb 3, 2015 at 2:39 AM, Yury Gribov wrote:
> On 01/23/2015 09:18 AM, Yury Gribov wrote:
>
>> Hi all,
>>
>> This patch sets up proper library path for SPEC benchmarks (otherwise
>> some tests fail because trunk libstdc++ uses some new symbols) and also
>> allows users to specify monitor_sp
Hi,
On Wed, Dec 3, 2014 at 3:59 PM, Kuba Brecka wrote:
> Hi everyone,
>
> I'd like to ask about the various symbolizers that are used by ASan and
> sanitizer_common, and then propose some changes to get better OS X support.
>
> If I understand correctly, the general llvm-symbolizer (and its inte
Hi,
Try to run the code with trunk LLVM/Clang. If the problem remains with the
latest Clang, then you'd have to wait a bit more - I have a tentative
change that is expected to improve debug info for local variables,
but it's not in the trunk yet.
On Fri, Oct 31, 2014 at 5:01 PM, texsetter wrote:
;t.
>
Sure. The relevant parts are ACCESS_MEMORY_RANGE and CHECK_RANGES_OVERLAP
macro in asan_interceptors.cc
> On Sep 26, 2014 8:52 AM, "'Alexey Samsonov' via address-sanitizer" <
> address-sanitizer@googlegroups.com> wrote:
>
>>
>> On Thu, Sep 2
h strcasecmp)
Sure. But it would be great to be able to disable interceptors in ASan
while still keeping __asan_report_error noreturn.
>
> On Thu, Sep 25, 2014 at 6:17 PM, 'Alexey Samsonov' via
> address-sanitizer wrote:
> > Can you add a new suppression kind that would d
when a suppression
> > matches the report that didn't originate from an interceptor)
> SGTM
>
> >
> > On Thu, Sep 25, 2014 at 4:08 AM, 'Alexey Samsonov' via
> > address-sanitizer wrote:
> >> I haven't looked at the code in a while, but this s
I haven't looked at the code in a while, but this should be possible. We
already have a global suppression context in sanitizer_common.
On Wed, Sep 24, 2014 at 4:47 PM, Konstantin Serebryany <
konstantin.s.serebry...@gmail.com> wrote:
> We probably can reuse lib/sanitizer_common/sanitizer_suppres
Hi,
This looks like
https://code.google.com/p/address-sanitizer/issues/detail?id=235. Recently
(but, I guess, after llvm-3.4.1) there were improvements in debug
information for local variables in ASan builds. Can you try tip-of-trunk
Clang on that example?
On Tue, Jul 15, 2014 at 6:41 PM, Shiny
On Tue, Jun 10, 2014 at 3:42 AM, 'Evgeniy Stepanov' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:
> On Tue, Jun 10, 2014 at 1:26 PM, Konstantin Serebryany
> wrote:
> > On Tue, Jun 10, 2014 at 12:50 PM, Yuri Gribov
> wrote:
> >>> there are downsides: one bug may trigger anoth
Hi Martin,
Thanks for experimenting.
On Sun, May 25, 2014 at 5:39 AM, Martin Ri wrote:
> The patch applied cleanly, but I'm still seeing problems.
>
> 189 UnsignedType GetBiased() const
> 190 {
> 191 UnsignedType const& key = reinterpret_cast const&>(value_);
> 192
20 matches
Mail list logo
