Solved Service in C: Resident set (column RES in ps) ever increasing?

[zirias@]

Well, in my "debug" build config, I add -fsanitize=address to both CFLAGS and LDFLAGS. This enables clang's runtime memory analyzer, which is quite nice and catches many addressing errors, but unfortunately, its leak checker is not supported on FreeBSD

So, when I'm looking for leaks, I use valgrind. It's an awesome tool overall and has other helpful checkers as well, e.g. I checked my threading code with its helgrind module (and found quite a few bugs to fix). Interestingly, helgrind still has a complaint when I'm initially starting up my threads and I really can't match it to anything in my code, so my guess now is it's something in FreeBSD's threading lib that's ok but not whitelisted in valgrind's ignore list yet… at least the address it complains about looks like it's in the text segment

==20001== ---Thread-Announcement------------------------------------------
==20001== 
==20001== Thread #3 was created
==20001==    at 0x49E139A: thr_new (in /lib/libc.so.7)
==20001==    by 0x488D4A4: pthread_create (in /lib/libthr.so.3)
==20001==    by 0x4855374: ??? (in /usr/local/libexec/valgrind/vgpreload_helgrind-amd64-freebsd.so)
==20001==    by 0x2179D1: ThreadPool_init (threadpool.c:295)
==20001==    by 0x212561: dmain (main.c:30)
==20001==    by 0x21250D: main (main.c:69)
==20001== 
==20001== ---Thread-Announcement------------------------------------------
==20001== 
==20001== Thread #2 was created
==20001==    at 0x49E139A: thr_new (in /lib/libc.so.7)
==20001==    by 0x488D4A4: pthread_create (in /lib/libthr.so.3)
==20001==    by 0x4855374: ??? (in /usr/local/libexec/valgrind/vgpreload_helgrind-amd64-freebsd.so)
==20001==    by 0x2179D1: ThreadPool_init (threadpool.c:295)
==20001==    by 0x212561: dmain (main.c:30)
==20001==    by 0x21250D: main (main.c:69)
==20001== 
==20001== ----------------------------------------------------------------
==20001== 
==20001== Possible data race during read of size 8 at 0x4860CD0 by thread #3
==20001== Locks held: none
==20001==    at 0x485E8C7: ??? (in /usr/local/libexec/valgrind/vgpreload_helgrind-amd64-freebsd.so)
==20001==    by 0x488D82A: ??? (in /lib/libthr.so.3)
==20001== 
==20001== This conflicts with a previous write of size 8 by thread #2
==20001== Locks held: none
==20001==    at 0x4006A6D: ??? (in /libexec/ld-elf.so.1)
==20001==    by 0x400A472: ??? (in /libexec/ld-elf.so.1)
==20001==    by 0x40063EC: ??? (in /libexec/ld-elf.so.1)
==20001==    by 0x485E8CB: ??? (in /usr/local/libexec/valgrind/vgpreload_helgrind-amd64-freebsd.so)
==20001==    by 0x488D82A: ??? (in /lib/libthr.so.3)
==20001==  Address 0x4860cd0 is in a rw- mapped file /usr/local/libexec/valgrind/vgpreload_helgrind-amd64-freebsd.so segment

 

[Paul Floyd]

Sorry I missed this. I can't tell much about the error from the traces you posted. Is it possible for you to share your source?

There is one known issue with Helgrind and TLS https://github.com/paulfloyd/freebsd_valgrind/issues/113 but this doesn't look like that.

Can you run the tests on a system with the core -dbg package installed?
Can you run the test application with vgdb and see if gdb tells you more about the error location?

To do that, in one terminal run
valgrind --tool=helgrind --vgdb-error=0 your_app arguments

Valgrind will tell you the command you need for vgdb

Then in another terminal run
gdb your_app
then paste the command from valgrind
'continue' (c) from the gdb prompt

Keep continuing until you get to the above error.

Then you can use 'bt' or 'where' to get the backtrace, and see if gdb gets more info.

If you like you can log an issue
1) on my github https://github.com/paulfloyd/freebsd_valgrind/issues
2) on the Valgrind bugzilla https://bugs.kde.org/enter_bug.cgi
(or the FreeBSD bugzilla, but the above two are better for me)