http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
--- Comment #2 from Alexey Samsonov <samsonov at google dot com> --- (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.
