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

samsonov at google dot com gcc-bugzilla@gcc.gnu.org
Fri Nov 15 07:34:00 GMT 2013


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

--- Comment #4 from Alexey Samsonov <samsonov at google dot com> ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Alexey Samsonov from comment #2)
> > 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
> 
> Well, POSIX is clear on what functions you can and what you can't call after
> fork in multi-threaded program.  You aren't calling exactly those functions,
> but functions that do the same thing as close/dup2/execl/_exit, that is
> fine, getdtablesize is not, but it just calls getrlimit syscall under the
> hood, which, while also not officially async-signal-safe, is safe in
> practice.
> 
> > 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.
> 
> It makes sense to start early only if you expect every program to be buggy
> and assume you will actually need to print something.
> 
> > > 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?
> 
> Yeah, I'm getting:
> llvm-symbolizer: Unknown command line argument '--default-arch=x86_64'. 
> Try: '/usr/bin/llvm-symbolizer -help'
> llvm-symbolizer: Did you mean '-disable-ssc=x86_64'?
> on stderr for all programs linked against libasan or liblsan.

We may fix this specific garbage output (by redirecting stderr to /dev/null, as
you proposed), but in general we can't provide a guarantee that ASan will work
with older versions of llvm-symbolizer, sorry. For example, our runtime code
may depend on new features of llvm-symbolizer which are only implemented in
LLVM trunk. E.g. w/o the --default-arch support we won't be able to symbolize
universal binaries (including ASan runtime itself) on Mac.

> 
> > > 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.
> 
> And in the case of the fork-bomb it would just keep the above mentioned text
> forever,
> because with LD_PRELOAD=./liblsan.so.0.0.0 in the environment also
> llvm-symbolizer itself
> was linked against liblsan and when it tried to run llvm-symbolizer eagerly,
> it would do that forever.
> If it started lazily, that would happen only if llvm-symbolizer was buggy
> and had to print something.



More information about the Gcc-bugs mailing list