This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug sanitizer/59136] llvm-symbolizer shouldn't be started always
- From: "kcc at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 14 Nov 2013 16:29:19 +0000
- Subject: [Bug sanitizer/59136] llvm-symbolizer shouldn't be started always
- Auto-submitted: auto-generated
- References: <bug-59136-4 at http dot gcc dot gnu dot org/bugzilla/>
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.