This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Kostya Serebryany from comment #25)
> Even with this workaround asan is almost unusable with the buggy kernel.
> I suspect that when a process has too many mappings it gets too slow.
> The machine where we have our clang-asan bootstrap gets very slow and
> unreliable.
> 
> We have reverted the kernel on that bot 
> (http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/)
> and reverted the above workaround in llvm trunk.
> http://llvm.org/viewvc/llvm-project?rev=200217&view=rev
> 
> The kernel fix went into Linus's tree for 3.14 last week,
> and was tagged for stable backport. Nothing else we could do here.

Yeah, except perhaps putting your #c24 testcase into the kernel bug as comment
for others to have quicker test than gimp, and perhaps filing bugs in distro
bugzillas to have this fixed there quicker, best mentioning that testcase.
Though, for a portable testcase that:
  char *p = (char*)0x600000000000;
is clearly undesirable, you probably just want to mmap with NULL base address,
perhaps with PROT_NONE, a .5GB region, then munmap it and use the result as p
(if that hasn't failed).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]