[Bug sanitizer/58718] Invalid check in libsanitizer

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718 Alexey Samsonov changed: What|Removed |Added CC||samsonov at google dot com --- Comment

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937 Alexey Samsonov changed: What|Removed |Added CC||eugeni.stepanov at gmail dot com,

[Bug sanitizer/59106] Failure to link against static libasan

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 Alexey Samsonov changed: What|Removed |Added CC||samsonov at google dot com --- Comment

[Bug sanitizer/59061] Port leaksanitizer

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #14 from Alexey Samsonov --- (In reply to Kostya Serebryany from comment #13) > > Why don't you use libbacktrace for that? It is not GPL, so Apple and other > > I *think* we evaluated libbacktrace over 2 years ago and > discarded fo

[Bug sanitizer/59136] llvm-symbolizer shouldn't be started always

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136 --- Comment #2 from Alexey Samsonov --- (In reply to Jakub Jelinek from comment #0) > I've noticed that libasan/liblsan now start external llvm-symbolizer for all > programs just in case they would be buggy, that looks like a very bad idea > to me

[Bug sanitizer/59136] llvm-symbolizer shouldn't be started always

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136 --- Comment #4 from Alexey Samsonov --- (In reply to Jakub Jelinek from comment #3) > (In reply to Alexey Samsonov from comment #2) > > We found it convenient to run fork+exec early at program startup. It can > > also be slightly dangerous to call

[Bug sanitizer/59136] [4.9 Regression] llvm-symbolizer shouldn't be started always

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136 --- Comment #6 from Alexey Samsonov --- (In reply to Richard Biener from comment #5) > No processes should be launched at all. Blocks the release - please make it > at least configurable to be able to turn it off. External process will only be l

[Bug sanitizer/59061] Port leaksanitizer

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #27 from Alexey Samsonov --- (In reply to Jakub Jelinek from comment #26) > libbacktrace doesn't use malloc (unless mmap isn't supported), handles > inline frames just fine and Ian has posted today a patch to support also > data symbol

[Bug sanitizer/59136] [4.9 Regression] llvm-symbolizer shouldn't be started always

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136 --- Comment #10 from Alexey Samsonov --- Hi! Jakub suggested to use libbacktrace in libsanitizer. I've committed his patch to LLVM, and it will soon be merged into GCC, with many more changes. So, your change will not be needed. I've also ensured

[Bug sanitizer/59136] [4.9 Regression] llvm-symbolizer shouldn't be started always

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136 --- Comment #13 from Alexey Samsonov --- I don't think fork() issue will be relevant here, at least for the minimalistic TSan test cases. Let's wait till we have libbacktrace symbolizer.

[Bug sanitizer/62307] -fsanitize=undefined doesn't pay attention to __attribute__((returns_nonnull))

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62307 --- Comment #3 from Alexey Samsonov --- FYI, Jakub has proposed a patch to add additional check to -fsanitize=undefined that would specifically sanitize functions with returns_nonnull attribute: however, it would sanitize bodies of the function a

[Bug sanitizer/63245] renderMemorySnippet shouldn't show more bytes than the underlying type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63245 --- Comment #2 from Alexey Samsonov --- This is also reported as http://llvm.org/bugs/show_bug.cgi?id=20721 I've mailed a patch that should at least fix the crashes: http://reviews.llvm.org/D5253. I agree that UBSan can do better, and actually ad