Re: Unexpected value-at for NULL'd pointer with pthreads

[Kyle Harper <kylejharper at gmail dot com>]

>> 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.