3 ms·

I have never heard about this (using valgrind with a "non-standard allocator"), but it looks really interesting, specially for other projects I am working on. I

• mananaysiempre 2y ago
  You can also integrate with AddressSanitizer to some extent, look into[1] ASAN_{UN,}POISON_MEMORY_REGION from <sanitizer/asan_interface.h> or the underlying intrinsics __asan_{un,}poison_memory_region. [1] https://github.com/google/sanitizers/wiki/AddressSanitizerManualPoisoning https://github.com/google/sanitizers/wiki/AddressSanitizerMa...
• kazinator 2y ago
  I integrated the TXR Lisp garbage collector with valgrind. That came in handy on a number of occasions. It's not always the case that you want special behavior for the garbage collector to assist with debugging, but also this: if you want to use Valgrind to debug anything that does not have to do with the garbage collector, you want all the false positives generated by it out of your way. Some of the scanning that a conservative garbage collector has to do looks like access errors to Valgrind. By using the Valgrind API, you can grant yourself access to that memory, and then lock it again when done. That aspect doesn't necessarily apply to a pool allocator being described in this article; that should not be triggering any false positives.
  • 8dcc 2y ago
    (In case you missed my other post, I ended up adding valgrind support in the article and in the 'libpool' project.) > I integrated the TXR Lisp garbage collector with valgrind. That's funny, because when I said "for other projects I am working on", I specifically meant a Lisp interpreter which uses a memory pool and garbage collection (I am still working on implementing this last part, anyway). I am very happy about the fact that I can continue using valgrind in this project.
    • kragen 2y ago
      This is awesome!