http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
Kostya Serebryany <kcc at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |glider at google dot com,
| |samsonov at google dot com
--- Comment #1 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(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.
Let Alexey and Alexander speak here.
This complexity should be gone completely once we make the in-process
symbolizer.
> 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.
> 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.
