search for: aizatsky

I'll need more details then. Maybe you can share the binary & its .sancov file? Or if you have a way to reproduce it? On Tue, Mar 7, 2017 at 1:23 PM Kostya Serebryany <kcc at google.com> wrote: > On Tue, Mar 7, 2017 at 12:50 PM, Mike Aizatsky <aizatsky at google.com> > wrote: > > Justin, > > I haven't seen this before. I suspect it is because of line-tables-only. > Can you try it with full debug info? > > > That would be strange. > -gline-tables-only is *the* recommended flag for all of the saniti...

Justin, I haven't seen this before. I suspect it is because of line-tables-only. Can you try it with full debug info? On Tue, Mar 7, 2017 at 12:36 PM Kostya Serebryany <kcc at google.com> wrote: > +aizatsky > > On Tue, Mar 7, 2017 at 12:34 PM, Justin Bogner <mail at justinbogner.com> > wrote: > > I'm working on a fuzzer using libFuzzer and I wanted to take a look at > how my coverage was doing, as per the instructions here: > > http://llvm.org/docs/LibFuzzer.html#ho...

Hi! My cron-based worker is being indeed invoked by backgroundRB at correct times. But... After several runs it can no longer find DB columns! The same query, which was running OK an hour ago starts to throw MySQL error about unkown column in where clause. If I restart backgroundrb it works for some time but stops working after several invocations. Has anyone epxerienced the similar beahviour?

FTR, I've disabled libcxx checkout on that particular bot <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer> to make it green. The problem remains, of course. :( On Sun, Dec 11, 2016 at 7:23 AM, James Knight <jyknight at google.com> wrote: > On Dec 11, 2016, at 3:33 AM, Eric Fiselier via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > So it

Hi! I''ve just a created a really simple rails scheduled worker for backgroundrb to start playing with : class SessionCleanerWorker < BackgrounDRb::Worker::RailsBase def do_work(args) logger.info "SessionCleaner> started" CGI::Session::ActiveRecordStore::Session.destroy_all( [''updated_at <?'', 120.minutes.ago] )

...not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: lib/Transforms/Instrumentation/SanitizerCoverage.cpp On Sat, Feb 27, 2016 at 9:00 AM Mike Aizatsky <aizatsky at chromium.org> wrote: > Renato, > > I did. And I thought I fixed it in http://reviews.llvm.org/rL262111 (as soon > as I got breakage notification). > > There's something wrong with those architectures. There are no problems on > others. I'll take bett...

I'm working on a fuzzer using libFuzzer and I wanted to take a look at how my coverage was doing, as per the instructions here: http://llvm.org/docs/LibFuzzer.html#how-good-is-my-fuzzer First of all, I suspect the instructions there are out of date, but passing -dump_coverage=1 to the binary rather than setting ASAN_OPTIONS generated a .sancov file for me. However, when I inspect this

Here's the error: [ 58%] Building CXX object projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.iossim.dir/sanitizer_procmaps_mac.cc.o [ 58%] Building CXX object projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.ios.dir/sanitizer_libc.cc.o [ 58%] Linking CXX shared library

On Dec 11, 2016, at 3:33 AM, Eric Fiselier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > So it seems that libatomic went missing between build #1379 and #1380, so I don't think this is related to the -std=c++11 failure. Instead it seems likely that the compile test for -std=c++11 is failing due to mis-configuring -latomic. > > Can you confirm the bot has libatomic

Bill, For some reason the llvm-symbolizer tests fail on ppc: http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/182/steps/ninja%20check%201/logs/stdio because it can't be started: /home/buildbots/ppc64le-clang-test/clang-ppc64le/stage1/./bin/llvm-symbolizer: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by

While debugging stale backgroundrb it became apparent that there''re memory leaks in it. Here''s top object counts dump: 36715 String 6211 Array 5598 Proc 3150 Hash 1478 DRb::DRbObject 1313 Regexp 1272 Class 750 Thread 741 Socket 739 Slave 739 Slave::LifeLine 737 Process::Status 691 DrillReminderWorker 391 Module 160 Range 75 Gem::Version

Hi! As you might remember I''m having a problem of backgroundrb stopping calling my workers after some period of time. I tried adding logging to backgroundrb source code but it didn''t help. So, after digging through internet I''ve found several gdb tools and here''s what I''ve discovered: After attaching to a backgroundrb ruby process it turns out that it