Solved Memory debugger for FreeBSD?

zirias@

Developer
Explaining the usecase first: I very rarely need a memory debugger. But WHEN I do, it's typically for the reason of having UB somewhere in my code that I just can't find. This often results in situations where the "debug build" seems to work perfectly, but the "release build" crashes or misbehaves somewhere, often not reproducible. A memory debugger often helps by finding things like:
  • off-by-one errors (out of bounds accesses)
  • use after free errors
  • use of uninitialized memory

For things like that, I used to use devel/valgrind (and DrMemory on Windows). Valgrind never worked perfectly on FreeBSD, I now don't remember what exactly was broken, but was still useful sometimes. Now, it is marked BROKEN: fails at runtime: valgrind: mmap(0x200000, 45056) failed in UME with error 22 (Invalid argument).

Is there any tool with the features described above I could use on FreeBSD instead?
 
Thanks, this is the right direction for sure. From reading all the description, what this tool won't be able to detect is using uninitialized memory, it should detect the other two errors I listed.

But then, there's no official repository anywhere, the version 2.2.2 in ports was released in 2000, and there seem to be some unofficial forks like this one: https://github.com/kallisti5/ElectricFence

Maybe I'll try it anyways, but still asking, does anyone know another similar tool that works fine on FreeBSD?
 
Does AddressSanitizer work on FreeBSD's clang (or GCC)? I can't seem to find a definitive answer. This would detect all of those issues.

I do tend to run Linux in a small VM, just for memory testing with Valgrind and Asan. It is a little annoying but I usually do it whilst also making a Linux port. I then chuck it through Intel Inspector for good measure if I ever have to make a Windows port.

I have personally found Asan to be more effective than Valgrind at detecting issues (and it runs a hell of a lot faster).

I have quite an invasive library for C that I use for greenfield projects if that could be of use? It will require manual instrumentation of standard C code to use however.
 
I do tend to run Linux in a small VM, just for memory testing with Valgrind and Asan. It is a little annoying but I usually do it whilst also making a Linux port. I then chuck it through Intel Inspector for good measure if I ever have to make a Windows port.
Of course I had this idea as well, will probably do it that way. It will be overhead though, cause normally, when I build for Linux or Windows, I use cross-compilers on FreeBSD.

That said, I never used AddressSanitizer. Will have to look into that, thanks!
 
Awesome, I've never used these, but it looks great. Might also add ubsan to the list of what to test, it really looks like fully replacing what I used valgrind for and adding even more. Thanks!
 
psearch -c devel -s memory debug
Code:
devel/dmalloc             Portable debug memory allocation library
devel/ElectricFence       Debugging malloc() that uses the VM hardware to detect buffer overruns
devel/libcwd              C++ Debugging Support Library
devel/libmaa              Provides a few data structures and helpful functions
devel/lmdbg               Lightweight malloc debugger
devel/mpatrol             Dynamic memory debugging and profiling library
devel/nana                Support for assertion checking and logging using GNU C and GDB
devel/oclgrind            SPIR interpreter and virtual OpenCL device simulator
devel/p5-Devel-RingBuffer Shared memory ring buffers for Perl scripts diagnosis/debug
devel/pecl-xdebug         Xdebug extension for PHP
devel/tass64              Multi pass optimizing macro assembler for 65xx series processors
devel/valgrind-devel      Memory debugging and profiling tool
devel/valgrind            Memory debugging and profiling tool
 
Explaining the usecase first: I very rarely need a memory debugger. But WHEN I do, it's typically for the reason of having UB somewhere in my code that I just can't find. This often results in situations where the "debug build" seems to work perfectly, but the "release build" crashes or misbehaves somewhere, often not reproducible. A memory debugger often helps by finding things like:
  • off-by-one errors (out of bounds accesses)
  • use after free errors
  • use of uninitialized memory
For things like that, I used to use devel/valgrind (and DrMemory on Windows). Valgrind never worked perfectly on FreeBSD, I now don't remember what exactly was broken, but was still useful sometimes. Now, it is marked BROKEN: fails at runtime: valgrind: mmap(0x200000, 45056) failed in UME with error 22 (Invalid argument).

Is there any tool with the features described above I could use on FreeBSD instead?

Use devel/valgrind-devel

This is actively maintained (by me!) and should work quite well.

In addition to the three types of error that you list, memcheck (the Valgrind memory checking tool) will also
* validate syscall parameters
* validate at the bit level
* check that new/new[]/malloc and delete/delete[]/free are used in the correct matching fashion
* check all user code that executes, including linked libraries - Sanitizers will only check code that has been instrumented

For stack memory, Valgrind will detect uninitialized use but it doesn't detect bounds overflows.

Valgrind also contains tools for thread hazard detection, time profiling and memory profiling.

Valgrind 3.17 is in the process of being released upstream. After that I'm planning on taking over devel/valgrind, and I'm hoping that the FreeBSD code will be accepted upstream for Valgrind 3.18.

If you see any errors with valgrind-devel (in Valgrind itself, not with your code), please either log an issue in the FreeBSD bugzilla or in my github repo.
 
Last edited:
Back
Top