http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (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. > > 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.
