Re: robust pthread_mutex_t in shared memory

[Michal Vaško]

Hi,
for anyone wondering, I manage to find out what the problem was. It is having a mutex on an address not dividable by 2, at least that is what it seems on my architecture x86. I have attached a simple program that always reproduces the problem for me. If I change HOLE_SIZE to a multiple of 2, it does not crash. Can anyone comment on this, please? Is this a bug?

Regards,
Michal

On Monday, April 15, 2019 12:06 CEST, Michal Vaško <mvasko@cesnet.cz> wrote:

> Hi Florian,
> sorry for not giving details but I do not know which are relevant and which not. Yes, munmap() followed by mmap() resulting in different address but there is no real backing file, the file descriptor passed to mmap() is obtained from shm_open().
>
> Regards,
> Michal
>
> On Monday, April 15, 2019 11:58 CEST, Florian Weimer <fweimer@redhat.com> wrote:
>
> > * Michal Vaško:
> >
> > > 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.
> >
> > What do you mean by “remapped”?  munmap followed by another mmap from
> > the backing file, possibly resulting in a different address?
> >
> > Thanks,
> > Florian
>
>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-csrc
Size: 1834 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-help/attachments/20190416/732adece/attachment.bin>