[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 #2 from Alexey Samsonov --- I've already fixed the problem with crashes caused by small "malloc_context_size" values. I think you should wait till the ASan runtime will be merged from LLVM into GCC.
[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, ||glider at google dot com --- Comment #5 from Alexey Samsonov --- +eugenis,glider Do we have any similar issues on systems where we use dynamic ASan runtime ourselves (Mac and Android)?
[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 #4 from Alexey Samsonov --- Yeah, in LLVM/Clang we build C++-specific part of UBSan with -frtti (and link it to C++ programs only), and the rest sanitizers with -fno-rtti.
[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 for some technical reason. Or was this something else? > Alexey? > We may want to re-evaluate it, but OTOH llvm-symbolizer works fine for us > already. I don't remember that, probably I should take a closer look at it. On a first glance, we'll still have to spend some effort to make it work fine with sanitizers - e.g. backtrace calls malloc, and likely other library functions. We must also ensure that it's able to unwind inlined frames, and debug info produced by -gline-tables-only/-gmlt. It works for ELF binaries only, while llvm-symbolizer supports Mach-O (and we use it on Mac). > > The symbolizer is pluggable so we may use another one in gcc. > > > > GPL haters can't complain, maintained by Google, and IMHO it is far better > > to just use existing code base for that rather than writing yet another > > DWARF parser. > > *We* are not writing yet another parser, we are reusing the code used by > lldb. Not really, we use a DWARF parser in LLVM, it's a fork of the one used in lldb. I think we'll be able to add support for certain DWARF GNU extensions to make it work with GCC-produced binaries. E.g. llvm-symbolizer already have basic support for DWAARF-5 Fission proposal. > > > Especially if you are writing it as part of llvm, it will unlikely handle > > all the DWARF GNU extensions needed to symbolize GCC code. > > Sure, there is work to be done on libbacktrace to handle some still > > unhandled extensions (e.g. DWZ produced extensions), but if you use > > libbacktrace, that can be done just in one spot, otherwise it will need to > > be written two times.
[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. It is quite a big overhead, and the usual case for sanitization > should be that no problems are reported, so IMNSHO if you really need > external symbolizer, at least start it on the first diagnostic output that > should be symbolized. We found it convenient to run fork+exec early at program startup. It can also be slightly dangerous to call fork() in multi-threaded program (even though we call exec soon after fork). Also, you've mentioned that starting a symbolizer introduces some overhead, and it would be nice to start printing error message ASAP (although, symbolizing the stack frame probably takes much more time). That said, I think your suggestion makes sense. I'll try to experiment with starting llvm-symbolizer lazily. > Furthermore, it doesn't have stderr redirected to /dev/null and passes by > default options e.g. llvm 3.3 llvm-symbolizer doesn't grok, so pretty much > for everything it emits ugly error messages. Not sure I understand it. Do you mean that when ASan runtime calls old version of llvm-symbolizer, it passes command-line options which are not recognized, and therefore fill the stderr with garbage? > And, when I've tried to LD_PRELOAD=./liblsan.so.0.0.0 ls -l > it because of the starting llvm-symbolizer just in case created a beatiful > fork-bomb.
[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 fork() in multi-threaded program (even > > though we call exec soon after fork). Also, you've mentioned that starting a > > Well, POSIX is clear on what functions you can and what you can't call after > fork in multi-threaded program. You aren't calling exactly those functions, > but functions that do the same thing as close/dup2/execl/_exit, that is > fine, getdtablesize is not, but it just calls getrlimit syscall under the > hood, which, while also not officially async-signal-safe, is safe in > practice. > > > symbolizer introduces some overhead, and it would be nice to start printing > > error message ASAP (although, symbolizing the stack frame probably takes > > much more time). That said, I think your suggestion makes sense. I'll try to > > experiment with starting llvm-symbolizer lazily. > > It makes sense to start early only if you expect every program to be buggy > and assume you will actually need to print something. > > > > Furthermore, it doesn't have stderr redirected to /dev/null and passes by > > > default options e.g. llvm 3.3 llvm-symbolizer doesn't grok, so pretty much > > > for everything it emits ugly error messages. > > > > Not sure I understand it. Do you mean that when ASan runtime calls old > > version of llvm-symbolizer, it passes command-line options which are not > > recognized, and therefore fill the stderr with garbage? > > Yeah, I'm getting: > llvm-symbolizer: Unknown command line argument '--default-arch=x86_64'. > Try: '/usr/bin/llvm-symbolizer -help' > llvm-symbolizer: Did you mean '-disable-ssc=x86_64'? > on stderr for all programs linked against libasan or liblsan. We may fix this specific garbage output (by redirecting stderr to /dev/null, as you proposed), but in general we can't provide a guarantee that ASan will work with older versions of llvm-symbolizer, sorry. For example, our runtime code may depend on new features of llvm-symbolizer which are only implemented in LLVM trunk. E.g. w/o the --default-arch support we won't be able to symbolize universal binaries (including ASan runtime itself) on Mac. > > > > And, when I've tried to LD_PRELOAD=./liblsan.so.0.0.0 ls -l > > > it because of the starting llvm-symbolizer just in case created a beatiful > > > fork-bomb. > > And in the case of the fork-bomb it would just keep the above mentioned text > forever, > because with LD_PRELOAD=./liblsan.so.0.0.0 in the environment also > llvm-symbolizer itself > was linked against liblsan and when it tried to run llvm-symbolizer eagerly, > it would do that forever. > If it started lazily, that would happen only if llvm-symbolizer was buggy > and had to print something.
[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 launched if a user has llvm-symbolizer binary in his PATH. This behaivor can also be turned off with a runtime option (ASAN_OPTIONS=symbolize=false).
[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 lookups. I think I'll post a > sanitizer_symbolizer_posix_libcdep.cc alternative > on Monday that will use libbacktrace, then users can at least choose what > they prefer, say at configure time. Awesome if you want to give it a try :) Note that support for in-process symbolization is already there. You may simply link in the library with functions __sanitizer_symbolize_code and __sanitizer_symbolize_data, and these functions will be picked up by ASan runtime and used instead of forking llvm-symbolizer. See InternalSymbolizer class in sanitizer_symbolizer_posix_libcdep.cc. We use this behavior in our private setup (i.e. we link with hermetic library version of llvm-symbolizer tool, built by a huge and ugly script).
[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 that, if you use llvm-symbolizer, it will not be started always, only when we actually need it to print a symbolized stack trace. Regarding "llvm-symbolizer: Unknown command line argument '--default-arch=x86_64'" failure: you see this because you don't use the trunk version of llvm-symbolizer binary. Sorry about that - we can keep ASan runtime in sync with LLVM head, but we surely get such dependency problems when we move it anywhere.
[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 and insert checks before return-statements to verify in runtime that the function actually doesn't return null.
[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 adjust the memory range it's going to print if some of it is unaccessible.
