пт, 12 июн. 2020 г. в 19:31, Willy Tarreau <w...@1wt.eu>: > Hi Ilya, > > On Mon, Mar 16, 2020 at 10:49:26AM +0100, Tim Düsterhus wrote: > > Ilya, > > > > Am 16.03.20 um 07:52 schrieb ???? ???????: > > > we use clang because of its address sanitizer. I found gcc asan more > noisy > > > and less usable. > > Going back to this, I spent the whole day trying to figure what broke > on travis to finally find that it's clang's broken ASAN which generates > bad code at -O2. Function b_alloc_margin() sees its "buf" pointer change > from valid to null in the middle of the function while not being assigned. > Just printing it or assigning it from itself is enough to stop the bug, I > suspect it's doing something wrong with the register where it placed the > pointer. I'm really fed up with this bogus address sanitizer, it has wasted > a huge amount of time and patience trying to find bugs that did not exist > and > because of this yet-another fake one I haven't finished addressing a real > one :-( > > Could we once for all disable this monster crap and mention in the commit > message that it must never be turned on until it stops doing stupid things > ? > > Sadly I couldn't find a way to detect it from within the code. I'd like > to prevent haproxy from being built with this crap without explicit > debug flags because the wrong code it produces triggers segfaults at > runtime in random locations and as such it's extremely dangerous. There's > definitely a risk that some people are not aware of its breakage and would > build haproxy with it and run it on their production, which is scary. If > anyone knows how to reliably detect it (ideally at build time), feel free > to suggest! >
it should be detectable using #if defined(__has_feature)# if __has_feature(address_sanitizer)// code that builds only under AddressSanitizer# endif#endif I agree to remove asan from travis. However, I still find it somewhat useful, I would add daily github action job with asan enabled (in the way it would not bother anymore). > Thanks, > Willy >
