On Tue, 2016-01-12 at 21:49 +0100, Johann Klammer wrote: > On 01/11/2016 02:12 PM, Paul Smith wrote: > > Yeah. Unfortunately this is a very complicated bit of code > > (implementing a thread-tolerant hash table completely in a header file > > using templates, so the method is inlined). > > > > I've confirmed that taking out optimization "solves" the problem in that > > my unoptimized test suite runs without any ASAN errors. > > > > I'll try to come up with a reduced test case. I'll see if I can run > > with ubsan but when I last tried it I got linker errors that I'll have > > to work around (I owe you a bug report for that as well). > > > > And you are sure it's not just out of memory/aspace? > ASAN needs a lot... Yes, quite sure. First I have 16G of RAM and the build servers have 24G :). Second, it works fine, as mentioned, if I don't compile with optimization enabled. Third, it fails exactly here every time even in very different workloads and even in two different programs that do different things, but happen to use these same data structures. One of them is a "data verification" tool which really doesn't use that much memory. I'm bogged down for a few days but I'll at least try to get a disassembly output for the generated code; my suspicion based on what I've seen so far is that the bug will be present in the generated assembly; it _feels_ to me like the optimizer is rearranging things such that the code is jumping to the ASAN reporter code when it shouldn't be. This is just a gut feeling so treat it as such. Trying to get a minimal repro case from source may take me a bit longer given the complexity of the code. Thanks!
