>> I did not see that link in any of your emails. It doesn't do >> anything about removing elements from lists. > > That's the first time I've seen that link too. > Weird. I must have not Reply-All'd correctly. Sorry about that. >>> Compiled with: >>> gcc -std=gnu99 -pthread -o grr grr.c >> >> You're freeing the same buffer twice. Thus your program crashes. > I understand that double-free()ing is a fatal access violate, however this shouldn't be happening in the first place. I am using pthread primitives (mutexes) to guard the critical section wherein I first free, then set to NULL the pointer that both threads are looking at. The first thread to reach the critical section should (and does) free() and NULL, then asserts that *buf == NULL. The second thread to reach the critical section should return without performing any action because of the if(*buf == NULL).... section, but it doesn't. Pthread mutexes should be guaranteeing proper memory fencing, but that doesn't appear to be the case. When thread 1 sets *buf = NULL it clearly has an effect on what thread 2 sees because thread 2 observes (*buf)->id as 0 instead of 123 in my example program. > Any of glibc, valgrind, asan or tsan diagnoses a use-after-free bug in > that code. I've been using valgrind (and helgrind) to attempt to see what's going on but it's still unclear. It will tell me "Invalid read of size bla..." but I already know that *buf is being read when it shouldn't be. I haven't figured out how to get it to show me how that's possible.
