Concurrent use of multiple hash tables

[Joseph Gray]

Hi.

I was using uthash in a program where 3 threads were using 3 different hash tables. Each thread independent of the others with no overlap of any kind.
When there was actual concurrent use of more than one hash table the program crashed in a nasty manner with a segmentation fault and all crash addresses were somewhere inside the uthash code.
When I replaced uthash with something simpler everything works fine...

This happened on RHEL 7.9 with gcc 11.4.

I wonder if anybody encountered anything similar.

Thanks.

Joseph Gray

[Joseph Gray]

Just to clarify.

I used no locking as I assumed the thread safety guide was for a single hash table.

Maybe that assumption was wrong.

[Arthur O'Dwyer]

On Sat, Mar 15, 2025 at 3:43 AM Joseph Gray <jgr...@gmail.com> wrote:

Hi.

I was using uthash in a program where 3 threads were using 3 different hash tables. Each thread independent of the others with no overlap of any kind.
When there was actual concurrent use of more than one hash table the program crashed in a nasty manner with a segmentation fault and all crash addresses were somewhere inside the uthash code.
When I replaced uthash with something simpler everything works fine...

This happened on RHEL 7.9 with gcc 11.4.

Most likely your code had a bug somewhere. Nothing within uthash itself prevents using two disjoint hash tables from two different threads simultaneously.

Of course it would cause a data race to read and write the same hash table from two different threads simultaneously, but you say you weren't doing that (at least not intentionally).

You might want to closely examine your code's use of `malloc` and `free`; for example, is it possible that you were accidentally accessing `p->some_data` after having called `free(p)`? That would generally "seem to work" in a single-threaded program, but possibly fail in a multithreaded program (if the block pointed to by `p` were already reallocated by a call to `malloc` in another thread, and modified by that thread).

Of course if you do come up with a reproducer, I'm happy to take a look. Post it here or (preferably) as a GitHub issue.

–Arthur