https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
--- Comment #14 from Bernd Edlinger <bernd.edlinger at hotmail dot de> --- (In reply to Jakub Jelinek from comment #7) > Note, I don't see any kind of memory leak on any of the testcases. > Sure, calling __tsan_func_entry many times is of course wrong. > As for #c5, clang doesn't call __tsan_func_exit in that case either. Dmitry? > If we were to call it even for exceptions, I'm afraid expanding this in tsan > pass is too late, we'd need to add the __tsan_func_exit call say during > gimplification as a cleanup of the whole body and then EH code would take > care of adding the needed landing pads etc. > But libtsan e.g. wraps longjmp and pops frames in there, not sure if it > doesn't do something similar for exceptions already. Hi Jakub, __tsan_func_entry pushes a few bytes on a call stack heap, and __tsan_func_exit pops these again. Therefore it is absolotely necessary to call these functions in pairs. If I run the a.out from the test cases, and I have the system monitor in the background, I can see my 8GB of memory quickly used up, and then my linux starts to page a lot so that it is hardly possible to press CTRL-C. There may of course also be a SIGSEGV in __tsan_func_entry when the heap finally overflows. Bernd.
