This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]