search for: kmaxnumchunks

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,...

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, > F...

+Aleksey, who has been dealing with the allocator recently. If you have a "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) check failure, it means that you've allocated (and did not deallocate) 2^18 large heap regions, each *at least* (2^17+1) bytes. This means, that you have live large heap chunks of 2^35 bytes (or more) in total, which is 32Gb. Does this sound correct? If yes, yea, I g...

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 a...

On Wed, Jan 24, 2018 at 11:30 AM, Kostya Serebryany <kcc at google.com> wrote: > +Aleksey, who has been dealing with the allocator recently. > > If you have a "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) > check failure, it means that you've allocated (and did not deallocate) 2^18 > large heap regions, each *at least* (2^17+1) bytes. > This means, that you have live large heap chunks of 2^35 bytes (or more) in > total, which is 32Gb. > Does this sound c...

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

...at 12:10 PM, Frederik Deweerdt < frederik.deweerdt at gmail.com> wrote: > On Wed, Jan 24, 2018 at 11:30 AM, Kostya Serebryany <kcc at google.com> > wrote: > > +Aleksey, who has been dealing with the allocator recently. > > > > If you have a "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) > > check failure, it means that you've allocated (and did not deallocate) > 2^18 > > large heap regions, each *at least* (2^17+1) bytes. > > This means, that you have live large heap chunks of 2^35 bytes (or more) > in > > total, which i...

...ello, > > 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...

Hello, On Wed, Jan 24, 2018 at 4:22 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Wed, Jan 24, 2018 at 12:10 PM, Frederik Deweerdt > <frederik.deweerdt at gmail.com> wrote: [...] >> >> > If yes, yea, I guess we need to bump kMaxNumChunks >> > >> > >> I'll increase the limit to 2^19 for our build, and I'll report the results >> here. > > I ended up increasing the limit to 2^20, because the max allocation for large objects is around 100G on those hosts. With that done, i hit an issue where...