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.
