Hello Kostya, I see that master has the same value for kMaxNumChunks, is there anything in particular that leads you to think i wouldn't run into the same limit? Thanks, Frederik On Tue, Jan 16, 2018 at 11:23 AM, Kostya Serebryany <kcc at google.com> wrote:> llvm 3.9 seems pretty old. > Does this happen with trunk? > > On Thu, Jan 11, 2018 at 11:20 AM, Frederik Deweerdt via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hello, >> >> We've had a build that hit the following assert: >> AddressSanitizer CHECK failed: >> >> /var/lib/jenkins/jenkins/workspace/fst-clang/local/src/llvm/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1078 >> "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) >> >> Increasing the limit and recompiling seems like the obvious >> workaround, but I'm wondering if i have better options than that. Any >> thoughts? >> >> Thank you, >> Frederik >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >
On Tue, Jan 16, 2018 at 11:44 AM, Frederik Deweerdt < frederik.deweerdt at gmail.com> wrote:> Hello Kostya, > > I see that master has the same value for kMaxNumChunks, is there > anything in particular that leads you to think i wouldn't run into the > same limit? >No. It's just that I haven't heard anyone else complain recently. If you have a reproducer that works on trunk, I'll be happy to look at it. --kcc> > Thanks, > Frederik > > On Tue, Jan 16, 2018 at 11:23 AM, Kostya Serebryany <kcc at google.com> > wrote: > > llvm 3.9 seems pretty old. > > Does this happen with trunk? > > > > On Thu, Jan 11, 2018 at 11:20 AM, Frederik Deweerdt via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> > >> Hello, > >> > >> We've had a build that hit the following assert: > >> AddressSanitizer CHECK failed: > >> > >> /var/lib/jenkins/jenkins/workspace/fst-clang/local/src/ > llvm/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../ > sanitizer_common/sanitizer_allocator.h:1078 > >> "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) > >> > >> Increasing the limit and recompiling seems like the obvious > >> workaround, but I'm wondering if i have better options than that. Any > >> thoughts? > >> > >> Thank you, > >> Frederik > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180116/d3677040/attachment.html>
On Tue, Jan 16, 2018 at 1:38 PM, Kostya Serebryany <kcc at google.com> wrote:>> I see that master has the same value for kMaxNumChunks, is there >> anything in particular that leads you to think i wouldn't run into the >> same limit? > > > No. It's just that I haven't heard anyone else complain recently. > If you have a reproducer that works on trunk, I'll be happy to look at it. >FWIW, I upgraded to 5.0.1, and we hit the issue again. We do not really have a repro available, in the sense that the box needs to receive traffic for a couple of hours in order for the build to hit the issue, it is however fairly consistent. Is there any instrumentation that we could add in order to understand the issue better, and in the meantime, is it safe to just increase the value for kMaxNumChunks ? Thanks, Frederik