Re: [Libunwind-devel] mincore_validate fails sometimes

[Daniel Vassdal]

Hi Dave,
Thanks for your reply.

Maybe I wasn't being entirely clear; the call to mincore() itself succeeded, 
i.e. returned 0.
However, when the result array is checked, one or more of the pages are not in 
memory.

If we have a look at commit bc8698fd, part of the commit comment says:
> we should also check that the pages are mapped, through the passed mvec 
> array. This patch
> also adds this verification.

I think the code that part of the code the comment refers to is this:
>  for (i = 0; i < (len + PAGE_SIZE - 1) / PAGE_SIZE; i++)
>   {
>     if (!(mvec[i] & 1)) return -1;
>   }

I'm not sure this is correct. According to the man page for mincore:
> mincore() returns a vector that indicates whether pages of the
> calling process's virtual memory are resident in core (RAM), and so
>  will not cause a disk access (page fault) if referenced.

Is this what the author intended to check?

Furthermore, the man page states hat mincore() can return
> ENOMEM addr to addr + length contained unmapped memory.

Thus it looks to me as if mincore() already returns an error code for what the 
comment says the block above is checking for.
This is a little out of my comfort zone so I may be talking nonsense, but maybe 
have a look at it?

- Daniel

-----Original Message-----
From: Dave Watson [mailto:address@hidden 
Sent: 16 January 2018 19:18
To: Daniel Vassdal <address@hidden>
Cc: address@hidden
Subject: Re: [Libunwind-devel] mincore_validate fails sometimes

On 01/15/18 12:00 PM, Daniel Vassdal wrote:
> We have an issue where on Yocto Morty 2.2 mincore_validate() sometimes 
> unexpectedly returns -1.
> This seems to happen most often directly after the system has been booted.

Do you know what the errno is when it returns -1?  Is there some condition we 
should be checking for?

> The check that fails is
> > if (!(mvec[i] & 1)) return -1;
> 
> The reason I suspect this is a libunwind problem is that when HAVE_MINCORE 
> isn't defined, it works well.
> This workaround is sufficient for us, but in case this indeed is a bug I 
> figured I'd let you guys know.