robust pthread_mutex_t in shared memory

Michal Vaško mvasko@cesnet.cz
Mon Apr 15 09:50:00 GMT 2019


Hi,
I have a use-case of process-shared mutexes in shared memory. The memory is even remapped at times but never while the lock is held. I have encountered some strange behavior and while debugging I wrote a fairly simple program that I would like to ask for help with. I would also appreciate if someone could tell me (or point me to where it is documented) what are the restrictions when using mutexes this way such as whether the memory can be remapped while a lock in it is held (probably not possible for robust mutexes, what about the default ones?) or similar ones.

In the use-case there is only a single thread and one shared memory segment with 2 mutexes intitialized with PTHREAD_PROCESS_SHARED, PTHREAD_MUTEX_ERRORCHECK, and PTHREAD_MUTEX_ROBUST attributes. After this initialization the memory is enlarged and remapped twice. After that no remapping is performed and following is the relevant output of the locks and unlocks (there are a few locks followed by unlocks of a single mutex).

<line> <lock address> <operation> <mutex memory hex print in 5x 8B chunks)

1 0x7fd2a08fb00f locking   0000000100000000 0000000000000000 0000000000000092 0000000000000000 0000000000000000
2 0x7fd2a08fb00f locked    0000000100006C76 0000000100006C76 0000000000000092 00007FD2A038DFE0 00007FD2A038DFE0
3 0x7fd2a08fb238 locking   0000000100000000 0000000000000000 0000000000000092 0000000000000000 0000000000000000
4 0x7fd2a08fb238 locked    0000000100006C76 0000000100006C76 0000000000000092 00007FD2A038DFE0 00007FD2A08FB02F
5 0x7fd2a08fb238 unlocking 0000000100006C76 0000000100006C76 0000000000000092 00007FD2A038DFE0 00007FD2A08FB02F
6 0x7fd2a08fb238 unlocked  0000000100000000 0000000000000000 0000000000000092 0000000000000000 0000000000000000
7 0x7fd2a08fb238 locking   0000000100000000 0000000000000000 0000000000000092 0000000000000000 0000000000000000
8 0x7fd2a08fb238 locked    0000000100006C76 0000000100006C76 0000000000000092 00007FD2A038DFE0 00007FD2A08FB02F
9 0x7fd2a08fb00f unlocking 0000000100006C76 0000000100006C76 5800000000000092 0000007FD2A08FB2 00007FD2A038DFE0

The last unlock crashes on DEQUEUE_MUTEX because it tries to access the invalid shifted address seen in the 4th mutex memory chunk on the line 9. On this line there is also the weird "58" at the beginning of the 3rd chunk. That "58" appears during ENQUEUE_MUTEX in locking on lines 3-4. That is as far as I got when debugging having no previous understanding of how mutexes work internally in GLIBC.

I can always reproduce this problem starting with having no shared memory created. I am on x86 OpenSUSE Tumbleweed with glibc 2.29-5.1. Any help will be very appreciated.

Regards,
Michal



More information about the Libc-help mailing list