search for: memcheck

I'm building a simple R extension around a CUDA-enabled dynamic library, and I want to run the whole package with cuda-memcheck for debugging purposes. I can run it just fine with Valgrind: $ R --no-save -d valgrind < test.R However, if I try the same thing with cuda-memcheck, $ R --no-save -d cuda-memcheck < test.R I get: *** Further command line arguments ('--no-save ') disregarded *** (maybe use 'r...

...e it will always help passes those needs smaller checks (i.e. loop distribution) Every pass has a different need of runtime check, i.e. vectorizer checks each memory against all others except (read vs read), loop distribution checks memory in different partition. Once we create a common superset memcheck how we will ensure there is no loss of opportunity for passes those have smaller checks. (i.e. loop distribution) Consider vectorizer generates memcheck for A, B, C, D addresses compare against each other and loop distribution generates memcheck for A,B vs C,D. Loop distribution actually don’t c...

Thanks for the feedback. Sounds like that at this point in time we can’t really settle on a single strategy. We probably want to support all of these uses-cases: 1. A common early loop-versioning pass, probably fairly conservative initially (e.g. if you need a single memcheck to remove all may-aliasing from a hight-trip-count loop it’s probably a good idea to version). Even if the pass would not be on by default, it would allow for quick experimentation and headroom studies. 2. Pass-specific loop-versioning scheduled right before the pass. One example here could be...

Hello llvmdev, I would like to propose and discuss yet another dynamic tool, which we call MemorySanitizer (msan). The main goal of the tool is to detect uses of uninitialized memory (the major feature of Valgrind/Memcheck not covered by AddressSanitizer). It will also find use-after-destruction-but-before-free in C++. The algorithm of the tool is similar to that of Memcheck ( http://static.usenix.org/event/usenix05/tech/general/full_papers/seward/seward.pdf ). We associate a few shadow bits with every byte of the a...

...d: > isZeroU > vex storage: T total 586404328 bytes allocated > vex storage: P total 640 bytes allocated > > valgrind: the 'impossible' happened: > LibVEX called failure_exit(). > > host stacktrace: > ==20179== at 0x38083F48: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==20179== by 0x38084064: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==20179== by 0x380842A1: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==20179== by 0x380842CA: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==20179== by 0x3809F682: ??? (in /u...

........ : ok vex: the `impossible' happened: isZeroU vex storage: T total 586404328 bytes allocated vex storage: P total 640 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==20179== at 0x38083F48: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==20179== by 0x38084064: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==20179== by 0x380842A1: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==20179== by 0x380842CA: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==20179== by 0x3809F682: ??? (in /usr/lib/valgrind/memc...

...t; > > There is a work taking place by multiple people in this area and more > is expected to happen and I’d like to make sure we’re working toward > a common end goal. > > > > > > I tried to collect the use-cases for run-time memory checks and the > specific memchecks required for each: > > > > > > 1. Loop Vectorizer: each memory access is checked against all other > memory accesses in the loop (except read vs read) > > > 2. Loop Distribution: only memory accesses in different partitions > are checked against each other....

...PM, Kostya Serebryany <kcc at google.com> wrote: > Hello llvmdev, > > I would like to propose and discuss yet another dynamic tool, which we > call MemorySanitizer (msan). > The main goal of the tool is to detect uses of uninitialized memory (the > major feature of Valgrind/Memcheck not covered by AddressSanitizer). > It will also find use-after-destruction-but-before-free in C++. > > The algorithm of the tool is similar to that of Memcheck ( > http://static.usenix.org/event/usenix05/tech/general/full_papers/seward/seward.pdf > ). > We associate a few shadow...

...ectorizer gained the ability to vectorize loops without explicit `llvm.loop` & `llvm.mem.parallel_loop_access` metadata. While that's awesome, there seems to be a regression in that `llvm.mem.parallel_loop_access` metadata doesn't make it into the alias analysis, and therefore a `vector.memcheck` basic block is inserted, where as before it was not. It's unclear if this is a regression, as I assume that if I upgrade my frontend to use the new alias metadata instead of the loop metadata then I would expect this problem to disappear. Please advise, happy to provide exemplar code if helpf...

...N ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, +# OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT +# OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +# SUCH DAMAGE. + +# Allow thread-local storage from pthread_create to leak. +{ + glibc_1 + Memcheck:Leak + fun:calloc + ... + fun:_dl_allocate_tls +} + +# Suppress leaks from dlopen. When running under valgrind we +# deliberately don't run dlclose because otherwise valgrind cannot +# print symbols. So it's expected that dlopen will leak. +{ + glibc_2 + Memcheck:Leak + ... + obj:/...

...ability to vectorize loops without explicit > `llvm.loop` & `llvm.mem.parallel_loop_access` metadata. While that's > awesome, there seems to be a regression in that > `llvm.mem.parallel_loop_access` metadata doesn't make it into the alias > analysis, and therefore a `vector.memcheck` basic block is inserted, where > as before it was not. > > There has been active development in this are to generalize LV’s > dependence analysis and memcheck infrastructure. The changes should not > have affected functionality minus bugs. If you have a testcase I can look > at...

On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger <joerg at britannica.bec.de > wrote: > On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya Serebryany wrote: > > Another difference from Memcheck is that we propose to use 8 shadow bits > > per byte of application memory and use a > > direct shadow mapping (for 64-bit linux that is just clearing 46-th bit > of > > the application memory address). > > This greatly simplifies the instrumentation code and avoids races...

...x storage: T total 586404328 bytes allocated >> vex storage: P total 640 bytes allocated >> >> valgrind: the 'impossible' happened: >> LibVEX called failure_exit(). >> >> host stacktrace: >> ==20179== at 0x38083F48: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) >> ==20179== by 0x38084064: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) >> ==20179== by 0x380842A1: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) >> ==20179== by 0x380842CA: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) >> ==20179== by 0x3809...

...ks specific to loop vectorizer, with this check we can’t use LAA for LICM loop versioning. > If we like to make this reusable probably we need to remove this or make it conditional. > > Probably, agents to LAA can implements such check instead LAA. > > Not really. Don’t you need memchecks for loop-invariant addresses as well? > We do need memcheck for loop-invariant addresses, but with current implementation if there is any invariant store, LAA simply returns by setting CanVecMem to false. > > I think we should just teach the analysis to also emit run-time checks for loo...

...nvariantStore’ (or a name with invariant store) makes more sense over ‘hasAccessToLoopInvariantAddress’. Right but it’s the address that’s invariant not the store so hasLoopInvariantStore is a misleading name. How about hasStoreToLoopInvariantAddress? > > You will also need to generate the memchecks for such accesses in > > canCheckPtrAtRT and addRuntimeCheck. Without those memchecks passing, > > the result of the dependence analysis is incorrect. > I did not understood this point correctly, I feel the current functionality take cares of it > And we do not need any new hand...

...05:19:11PM +0400, Kostya Serebryany wrote: > > On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger < > joerg at britannica.bec.de > > > wrote: > > > > > On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya Serebryany wrote: > > > > Another difference from Memcheck is that we propose to use 8 shadow > bits > > > > per byte of application memory and use a > > > > direct shadow mapping (for 64-bit linux that is just clearing 46-th > bit > > > of > > > > the application memory address). > > > > This...

On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya Serebryany wrote: > Another difference from Memcheck is that we propose to use 8 shadow bits > per byte of application memory and use a > direct shadow mapping (for 64-bit linux that is just clearing 46-th bit of > the application memory address). > This greatly simplifies the instrumentation code and avoids races on shadow > updates &...

On Mon, Jun 18, 2012 at 05:19:11PM +0400, Kostya Serebryany wrote: > On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger <joerg at britannica.bec.de > > wrote: > > > On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya Serebryany wrote: > > > Another difference from Memcheck is that we propose to use 8 shadow bits > > > per byte of application memory and use a > > > direct shadow mapping (for 64-bit linux that is just clearing 46-th bit > > of > > > the application memory address). > > > This greatly simplifies the instrumentat...

Hi, We are having an issue with the loop vectorizer and noalias pointers, as it is generating `vector.memcheck` while we can guarantee that the pointers will not overlap. It seems that in `LoopVectorize.cpp` the function `emitMemRuntimeChecks` is called but there are no checks to disable this behavior (like "strong noalias") We are actually using a technique similar to the llvm.noalias (https://...

...t; On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger < > > > joerg at britannica.bec.de > > > > > wrote: > > > > > > > > > On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya Serebryany wrote: > > > > > > Another difference from Memcheck is that we propose to use 8 > shadow > > > bits > > > > > > per byte of application memory and use a > > > > > > direct shadow mapping (for 64-bit linux that is just clearing > 46-th > > > bit > > > > > of > > > &gt...