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] New: llvm-symbolizer shouldn't be started always


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136

            Bug ID: 59136
           Summary: llvm-symbolizer shouldn't be started always
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

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.
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]