https://bugs.kde.org/show_bug.cgi?id=511717
--- Comment #35 from Philippe Waroquiers <[email protected]> --- (In reply to Libor Peltan from comment #34) > Happy New Year Philippe, Happy new year for you too. > thanks much for your analysis! > > I confirm that with the above patch to coregrind/m_syswrap/syswrap-generic.c > , the perceived issue disappears. Thanks for the quick feedback. > > Anyway, is there anything (e.g. compile options, tiny code changes...) we > can do in our software (Knot DNS) to prevent glibc from this new behavior in > order to workaround the issue on our side, before a solution in Valgrind is > found? I have not seen in glibc code any flag or tunable to force glibc to use mprotect. I believe the only way to do that from the application side is to have the program allocating the thread stack (using e.g. mmap) and using mprotect+pthread_attr_setstack > > My expectation is that with the new Ubuntu LTS on April, the newer glibc > will be used more widely by everyone. Effectively with next Ubuntu LTS (and with other distributions switching to a newer glibc), this problem will become much more frequent. IMO, we should put a fix in valgrind in the coming months. If finally we believe that what needs to be done is to make valgrind address space manager more intelligent; we might still in the meantime commit the patch you have tried as a temporary measure. -- You are receiving this mail because: You are watching all bug changes.
