similar to: Hitting kMaxNumChunks

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

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

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

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

On Wed, Jan 24, 2018 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

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

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

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

I ran "ninja check-asan" and no errors. But "ninja check-msan" had 117 errors. I took the first FAILED test, which was for eventfd.cc, and executed the command line creating an eventfd executable in a temporary directory and then executed that file using gdb. Finally, used bt to dump the stack. I've emailed llvm-admin at lists.llvm.org to setup an account since

I've "successfully" built 3.9.0 release but when I run "ninja check-all" I got 208 Unexpected failures: Expected Passes : 33997 Expected Failures : 198 Unsupported Tests : 685 Unexpected Failures: 208 Below is the log I captured running "time ninja check-all | tee ninja-check-all.txt" https://drive.google.com/open?id=0B-KTY7zi7eZHU2hGYTRtd01QZjA

> We have plans to actually compile the symbolizer into the binary and do > in-process symbolization, but it's not there yet. nice! > I'm confused here. compiler-rt and clang/llvm instrumentation depend on each other These two projects don't need to be interdependent and, for the most part, they aren't. In the same way that llvm does not depend on clang, compiler-rt

On Thu, May 30, 2013 at 10:05 PM, Greg Fitzgerald <garious at gmail.com> wrote: > The sanitizer common and asan that mention 'thread' are failing for me > this morning. How are your bots looking? Last good commit here was > 512c616cacf70ca029a2bf719a482b902f3687cd. > Hm, our bots seem to be green. Could you refer to guilty svn revision? > > > You could try

I've compiled REALEASE_390/final but all "ninja check-msan" tests are failing (http://lists.llvm.org/pipermail/llvm-dev/2016-September/104609.html) I'm waiting for an account to be created to file a bug, but in the mean time I thought I'd take a look at it myself. My system is an Arch Linux system that is up to date as of this morning: $ uname -a Linux wink-desktop

The sanitizer common and asan that mention 'thread' are failing for me this morning. How are your bots looking? Last good commit here was 512c616cacf70ca029a2bf719a482b902f3687cd. > You could try preprocessing your report with perl or sed to fix paths > to your binaries. It would be great to have an option for that in > asan_symbolize.py. > > As for addr2line, we just

On Wed, Jul 13, 2016 at 04:48:51PM +0200, Sedat Dilek via llvm-dev wrote: > [ CCed all people who were involved in this thread ] > > Hi Tom, > > personally, I am interested to test the prebuilt-toolchains for > Ubuntu/xenial alias 16.04 LTS and Debian/Jessie v8.5.0 AMD64. > The available toolchains are incomplete and thus useless. > > Just as a fact: There is still no

Hi guys, I am following this[1] tutorial to install clang. However, I have made a small change in the configure command, and I am running it with '--enable-optimized' option to avoid the debug build. I am getting the errors (given at the end) related to *undeclared identifiers '__NR_*'*. Can someone please provide some input about how to tackle this issue? On my other machine, I

Hi, I see that ENABLE_WERROR is being set to off (the default value) in the config.log in the llvm build. However on grepping for WERROR in the compiler-rt folder I get the following output: pranav at pranav:~/smack-project/llvm-3.4/src/projects/compiler-rt$ grep -Rin WERROR * lib/asan/tests/CMakeLists.txt:38: -Werror lib/asan/asan_malloc_mac.cc:253:// This function is currently unused, and we

Dear Alexey, Yes I am sure that the llvm, clang and compiler-rt are synced to the same version. I downloaded them all from git http://llvm.org/docs/GettingStarted.html#git-mirror I think I need compiler-rt for my project but I'll verify it again to see if I can proceed without it. You are correct that compiler-rt is compiled with the just built clang. The complete command that gives an error

Hi all, I experienced some test failures under Linux, probably caused by r232936: In the test SanitizerCommon-Unit :: Sanitizer-i386-Test/MemoryMappingLayout.CodeRange the temporary test file was opened write-only, but was read from, what subsequently failed: Note: Google Test filter = MemoryMappingLayout.CodeRange [==========] Running 1 test from 1 test case. [----------] Global test

yes I think that is correct. I wrote a simple program to print if sizeof(uintptr_t) != sizeof(unsigned char *) and when I compile with gcc -m64 and execute it on a 64-bit host (that is different from the 32-bit laptop on which I originally compiled the program), it says the sizes are not equal. Thanks Pranav On Thu, Aug 1, 2013 at 9:29 AM, Alexey Samsonov <samsonov at google.com> wrote: