On Fri, Jun 12, 2020 at 08:57:44PM +0500, ???? ??????? wrote: > ??, 12 ???. 2020 ?. ? 20:46, Willy Tarreau <w...@1wt.eu>: > > > On Fri, Jun 12, 2020 at 08:11:52PM +0500, ???? ??????? wrote: > > > > Has it ever reported a *real* issue ? I mean, we've been working around > > > > > > > > > > > > > https://github.com/haproxy/haproxy/issues/96 > > > https://github.com/haproxy/haproxy/issues/104 > > > https://github.com/haproxy/haproxy/issues/106 > > > https://github.com/haproxy/haproxy/issues/111 > > > > Well only two above are the address sanitizer, one is valgrind and the > > other one is the thread sanitizer. > > > > > and I hope that William Lallemand also found and fixed about 5 bugs > > > detected by travis + asan > > > > Maybe. > > > > In that case at least we should run it at -O1. It's at -O2 that it > > produces bogus code from what I'm seeing. And given that the docs > > also suggest -O1 to get a usable backtrace, it's possible that it's > > rarely tested in combination with -O2. But anyway I really *hate* > > seeing compilers silently emit bad code, especially when it happens > > when asking them to detect more anomalies! > > > > I may try to report it. Is there small repro code ?
Sadly not, as usual with bad code. It dies in b_alloc_margin() with a NULL "buf" (long after having successfully dereferenced it) when getting the first H2 request. Putting a printf() in the caller (h2_get_buf) is usually enough to stop the bug. However a printf in the caller doesn't change anything, which could indicate that we may succeed in isolating these functions. I saw it crash when buf was assigned to rbx register, maybe it's occasionally clobbered by their functions, I don't know. I've spent way too much time on it now. I may try to elaborate a repro later but I have way more important things to do than trying to debug an experimental tool that's broken in other areas anyway :-/ Willy
