Why do these mprotect always fail?

Why do these mprotect always fail?

[w6b7rk5yu4mt25v3]

mprotect 1:

    unsigned char* buffer;
    int32_t available, size;

      if(size > PAGE_SIZE) {
        factor = size / PAGE_SIZE + 1;
      }
      available = factor * PAGE_SIZE;

      if(posix_memalign((void**)&buffer, PAGE_SIZE, available)) {
        std::wcerr << L"Unable to allocate JIT memory!" << std::endl;
        exit(1);
      }
      if(mprotect(buffer, available, PROT_READ | PROT_WRITE | PROT_EXEC) < 0) {
        std::wcerr << L"Unable to mprotect" << std::endl;
        exit(1);
      }

mprotect 2:

  if(posix_memalign((void**)& buffer, PAGE_SIZE, PAGE_SIZE)) {
    std::wcerr << L"Unable to allocate JIT memory!" << std::endl;
    exit(1);
  }

  if(mprotect(buffer, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC) < 0) {
    std::wcerr << L"Unable to mprotect" << std::endl;
    exit(1);
  }


Sent with Proton Mail secure email.

Re: Why do these mprotect always fail?

[w6b7rk5yu4mt25v3]

Almost forgot, PAGE_SIZE is set to 4096. This is a Linux application, when I compile on Cygwin it complained that PAGE_SIZE is redefined but the compilation was success nevertheless. Only when I run the application, I always exited with "Unable to mprotect".

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, February 15th, 2023 at 16:38, w6b7rk5yu4mt25v3 <w6b7rk5yu4mt25v3@protonmail.com> wrote:


> mprotect 1:
> 
> unsigned char* buffer;
> int32_t available, size;
> 
> if(size > PAGE_SIZE) {
> 
> factor = size / PAGE_SIZE + 1;
> }
> available = factor * PAGE_SIZE;
> 
> if(posix_memalign((void**)&buffer, PAGE_SIZE, available)) {
> std::wcerr << L"Unable to allocate JIT memory!" << std::endl;
> exit(1);
> }
> if(mprotect(buffer, available, PROT_READ | PROT_WRITE | PROT_EXEC) < 0) {
> std::wcerr << L"Unable to mprotect" << std::endl;
> exit(1);
> }
> 
> mprotect 2:
> 
> if(posix_memalign((void**)& buffer, PAGE_SIZE, PAGE_SIZE)) {
> std::wcerr << L"Unable to allocate JIT memory!" << std::endl;
> exit(1);
> }
> 
> if(mprotect(buffer, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC) < 0) {
> std::wcerr << L"Unable to mprotect" << std::endl;
> exit(1);
> }
> 
> 
> Sent with Proton Mail secure email.

Re: Why do these mprotect always fail?

[Corinna Vinschen]

cygwin-developers is for developers woking on Cygwin itself, not for
developers using Cygwin to develop something else.  I dropped the ML
from the recipient list.

And please don't top-post.  Thanks.

On Feb 15 09:43, w6b7rk5yu4mt25v3 via Cygwin wrote:
> Almost forgot, PAGE_SIZE is set to 4096. This is a Linux application,
> when I compile on Cygwin it complained that PAGE_SIZE is redefined but
> the compilation was success nevertheless. Only when I run the
> application, I always exited with "Unable to mprotect".

PAGESIZE is 64K on Cygwin.  If you change that, it breaks and you can
keep the pieces.

It would be nice to send a complete, self-contained STC(*) in plain C,
so reproducing your issue is simple and doesn't require to rework
your code to get a running, debuggable testcase.


Corinna


(*) https://cygwin.com/acronyms/#STC

Fw: Re: Why do these mprotect always fail?

[w6b7rk5yu4mt25v3]

PAGE_SIZE is just a naming conflict. If you change it to something else, JIT_PAGE_SIZE for example, it still fails. The problem is Cygwin is not fine with the particular value 4096 but the program needs the value to be exactly 4096. About why I also sent to developer list, see:

https://cygwin.com/pipermail/cygwin-developers/2020-July/011913.html

https://cygwin.com/pipermail/cygwin/2002-January/068158.html

This problem is well known at least.

Sent with Proton Mail secure email.

------- Forwarded Message -------
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
Date: On Wednesday, February 15th, 2023 at 17:32
Subject: Re: Why do these mprotect always fail?
To: cygwin@cygwin.com <cygwin@cygwin.com>
CC: w6b7rk5yu4mt25v3 <w6b7rk5yu4mt25v3@protonmail.com>


> cygwin-developers is for developers woking on Cygwin itself, not for
> developers using Cygwin to develop something else. I dropped the ML
> from the recipient list.
> 
> And please don't top-post. Thanks.
> 
> On Feb 15 09:43, w6b7rk5yu4mt25v3 via Cygwin wrote:
> 
> > Almost forgot, PAGE_SIZE is set to 4096. This is a Linux application,
> > when I compile on Cygwin it complained that PAGE_SIZE is redefined but
> > the compilation was success nevertheless. Only when I run the
> > application, I always exited with "Unable to mprotect".
> 
> 
> PAGESIZE is 64K on Cygwin. If you change that, it breaks and you can
> keep the pieces.
> 
> It would be nice to send a complete, self-contained STC() in plain C,
> so reproducing your issue is simple and doesn't require to rework
> your code to get a running, debuggable testcase.
> 
> 
> Corinna
> 
> 
> () https://cygwin.com/acronyms/#STC

Re: Fw: Re: Why do these mprotect always fail?

[Corinna Vinschen]

On Feb 15 11:14, w6b7rk5yu4mt25v3 via Cygwin wrote:
> Corinna Vinschen wrote:
> 
> > cygwin-developers is for developers woking on Cygwin itself, not for
> > developers using Cygwin to develop something else. I dropped the ML
> > from the recipient list.
> > 
> > And please don't top-post. Thanks.
> > 
> > On Feb 15 09:43, w6b7rk5yu4mt25v3 via Cygwin wrote:
> > 
> > > Almost forgot, PAGE_SIZE is set to 4096. This is a Linux application,
> > > when I compile on Cygwin it complained that PAGE_SIZE is redefined but
> > > the compilation was success nevertheless. Only when I run the
> > > application, I always exited with "Unable to mprotect".
> > 
> > 
> > PAGESIZE is 64K on Cygwin. If you change that, it breaks and you can
> > keep the pieces.
> > 
> > It would be nice to send a complete, self-contained STC() in plain C,
> > so reproducing your issue is simple and doesn't require to rework
> > your code to get a running, debuggable testcase.
> 
> PAGE_SIZE is just a naming conflict. If you change it to something
> else, JIT_PAGE_SIZE for example, it still fails.

You're misunderstanding what PAGESIZE or PAGE_SIZE means.  It's the
system page size used for mappings, and it's a fixed value defined by
the system and provided to you by the system headers and, especially,
sysconf(_SC_PAGE_SIZE).

It's *NOT* something you can just change and think the result will still
work.  Especially given that mmap doesn't know that you changed a macro
in your application code...

> The problem is Cygwin
> is not fine with the particular value 4096 but the program needs the
> value to be exactly 4096.

Sorry, but that can't work.  If the program actually demands it, it's
non-portable.


Corinna

Re: Fw: Re: Why do these mprotect always fail?

[w6b7rk5yu4mt25v3]

You misunderstood what I said.

It's really just a naming conflict and a coincident. On the context of the source code (it's an interpreter), PAGE_SIZE is indeed JIT_PAGE_SIZE (not the system page size, but the page size defined internally by the interpreter). On Linux, the name doesn't conflict. On Cygwin, I found on limits.h and cygwin/limits.h already defined PAGE_SIZE so it caused a naming conflict:

#define __PAGESIZE 65536
#define PAGESIZE __PAGESIZE
#define PAGE_SIZE PAGESIZE

But the problem not related to the naming conflict. If I renamed PAGE_SIZE to JIT_PAGE_SIZE, the problem is still there. The problem is Cygwin will not work with JIT_PAGE_SIZE = 4096. Please have a look at the code I posted. It will always error with "Unable to mprotect".

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, February 15th, 2023 at 19:13, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:


> On Feb 15 11:14, w6b7rk5yu4mt25v3 via Cygwin wrote:
> 
> > Corinna Vinschen wrote:
> > 
> > > cygwin-developers is for developers woking on Cygwin itself, not for
> > > developers using Cygwin to develop something else. I dropped the ML
> > > from the recipient list.
> > > 
> > > And please don't top-post. Thanks.
> > > 
> > > On Feb 15 09:43, w6b7rk5yu4mt25v3 via Cygwin wrote:
> > > 
> > > > Almost forgot, PAGE_SIZE is set to 4096. This is a Linux application,
> > > > when I compile on Cygwin it complained that PAGE_SIZE is redefined but
> > > > the compilation was success nevertheless. Only when I run the
> > > > application, I always exited with "Unable to mprotect".
> > > 
> > > PAGESIZE is 64K on Cygwin. If you change that, it breaks and you can
> > > keep the pieces.
> > > 
> > > It would be nice to send a complete, self-contained STC() in plain C,
> > > so reproducing your issue is simple and doesn't require to rework
> > > your code to get a running, debuggable testcase.
> > 
> > PAGE_SIZE is just a naming conflict. If you change it to something
> > else, JIT_PAGE_SIZE for example, it still fails.
> 
> 
> You're misunderstanding what PAGESIZE or PAGE_SIZE means. It's the
> system page size used for mappings, and it's a fixed value defined by
> the system and provided to you by the system headers and, especially,
> sysconf(_SC_PAGE_SIZE).
> 
> It's NOT something you can just change and think the result will still
> work. Especially given that mmap doesn't know that you changed a macro
> in your application code...
> 
> > The problem is Cygwin
> > is not fine with the particular value 4096 but the program needs the
> > value to be exactly 4096.
> 
> 
> Sorry, but that can't work. If the program actually demands it, it's
> non-portable.
> 
> 
> Corinna

Re: Fw: Re: Why do these mprotect always fail?

[Oskar Skog]

[-- Attachment #1.1.1: Type: text/plain, Size: 1275 bytes --]

On 2023-02-15 14:40, w6b7rk5yu4mt25v3 via Cygwin wrote:
> You misunderstood what I said.
> 
> It's really just a naming conflict and a coincident. On the context of the source code (it's an interpreter), PAGE_SIZE is indeed JIT_PAGE_SIZE (not the system page size, but the page size defined internally by the interpreter). On Linux, the name doesn't conflict. On Cygwin, I found on limits.h and cygwin/limits.h already defined PAGE_SIZE so it caused a naming conflict:
> 
> #define __PAGESIZE 65536
> #define PAGESIZE __PAGESIZE
> #define PAGE_SIZE PAGESIZE
> 
> But the problem not related to the naming conflict. If I renamed PAGE_SIZE to JIT_PAGE_SIZE, the problem is still there. The problem is Cygwin will not work with JIT_PAGE_SIZE = 4096. Please have a look at the code I posted. It will always error with "Unable to mprotect".

The Linux man page for mprotect says that the address MUST be aligned
(with the systems PAGE_SIZE).  Your call to posix_memalign is NOT
aligning the allocation with the systems PAGE_SIZE (65536), but with
your PAGE_SIZE (4096).

You need to allocate memory that is aligned with the systems PAGE_SIZE.

Eg.
if(posix_memalign((void**)&buffer, (PAGE_SIZE>JIT_PAGE_SIZE) ? PAGE_SIZE 
: JIT_PAGE_SIZE, available)) { ... }

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2485 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

Re: Fw: Re: Why do these mprotect always fail?

[Corinna Vinschen]

On Feb 15 12:40, w6b7rk5yu4mt25v3 via Cygwin wrote:
> On Wednesday, February 15th, 2023 at 19:13, Corinna Vinschen wrote:
> > On Feb 15 11:14, w6b7rk5yu4mt25v3 via Cygwin wrote:
> > > Corinna Vinschen wrote:
> > > 
> > > > cygwin-developers is for developers woking on Cygwin itself, not for
> > > > developers using Cygwin to develop something else. I dropped the ML
> > > > from the recipient list.
> > > > 
> > > > And please don't top-post. Thanks.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> > [...]
> > You're misunderstanding what PAGESIZE or PAGE_SIZE means. It's the
> > system page size used for mappings, and it's a fixed value defined by
> > the system and provided to you by the system headers and, especially,
> > sysconf(_SC_PAGE_SIZE).
> > 
> > It's NOT something you can just change and think the result will still
> > work. Especially given that mmap doesn't know that you changed a macro
> > in your application code...
> > 
> > > The problem is Cygwin
> > > is not fine with the particular value 4096 but the program needs the
> > > value to be exactly 4096.
> > 
> > 
> > Sorry, but that can't work. If the program actually demands it, it's
> > non-portable.
> 
> You misunderstood what I said.
> 
> It's really just a naming conflict and a coincident. On the context of
> the source code (it's an interpreter), PAGE_SIZE is indeed
> JIT_PAGE_SIZE (not the system page size, but the page size defined
> internally by the interpreter). On Linux, the name doesn't conflict.
> On Cygwin, I found on limits.h and cygwin/limits.h already defined
> PAGE_SIZE so it caused a naming conflict:
> 
> #define __PAGESIZE 65536
> #define PAGESIZE __PAGESIZE
> #define PAGE_SIZE PAGESIZE
> 
> But the problem not related to the naming conflict. If I renamed
> PAGE_SIZE to JIT_PAGE_SIZE, the problem is still there. The problem is
> Cygwin will not work with JIT_PAGE_SIZE = 4096. Please have a look at
> the code I posted. It will always error with "Unable to mprotect".

Again, it doesn't matter what your application is doing with PAGE_SIZE.
PAGE_SIZE in limits.h is a read-only value to inform your application
about the system page size.  Just because your application overwrites
PAGE_SIZE doesn't change the fact that the system's mmap uses the real
page size, i. e., 64K.

Look, let's make a Windows example:

Somewhere in the headers there's a definition

  # define MAX_PATH 260

This defines the maximum path length when using the Windows ANSI File
API, for instance, CreateFileA().

Now you go ahead and overwrite this value in your application:

  #undef MAX_PATH
  #define MAX_PATH 1024

Do you really think that the Windows functions will even notice that
you changed MAX_PATH in your application and they will suddenly happily
work with 1K paths?  No, they won't.

And it's, hopefully obviously, the same with mmap and mprotect.  Just
because you define your own PAGE_SIZE value doesn't mean the system will
even see this.  It will continue to use the real page size value, as
returned by sysconf(_SC_PAGE_SIZE), and mprotect will fail if the
address isn't given in multiples of sysconf(_SC_PAGE_SIZE).


Corinna

Fw: Re: Fw: Re: Why do these mprotect always fail?

[w6b7rk5yu4mt25v3]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

I asked the developer of the interpreter. He said it's OK to use the PAGE_SIZE value different than 4096. So I used this dirty hack:

#ifndef __CYGWIN__
#define PAGE_SIZE 4096
#endif

This means on Cygwin it will use the default PAGE_SIZE defined on limits.h (I'm taking advantage of the naming conflict here so I don't have to rename PAGE_SIZE to JIT_PAGE_SIZE as suggested by the developer of the interpreter).

The result is it's no longer error with "Unable to mprotect" but will silently crashed without any error messages printed on the screen. So after all, it's Cygwin's quirks here.

Sent with Proton Mail secure email.

------- Forwarded Message -------
From: Oskar Skog via Cygwin <cygwin@cygwin.com>
Date: On Wednesday, February 15th, 2023 at 20:02
Subject: Re: Fw: Re: Why do these mprotect always fail?
To: cygwin@cygwin.com <cygwin@cygwin.com>


> On 2023-02-15 14:40, w6b7rk5yu4mt25v3 via Cygwin wrote:
> 
> > You misunderstood what I said.
> > 
> > It's really just a naming conflict and a coincident. On the context of the source code (it's an interpreter), PAGE_SIZE is indeed JIT_PAGE_SIZE (not the system page size, but the page size defined internally by the interpreter). On Linux, the name doesn't conflict. On Cygwin, I found on limits.h and cygwin/limits.h already defined PAGE_SIZE so it caused a naming conflict:
> > 
> > #define __PAGESIZE 65536
> > #define PAGESIZE __PAGESIZE
> > #define PAGE_SIZE PAGESIZE
> > 
> > But the problem not related to the naming conflict. If I renamed PAGE_SIZE to JIT_PAGE_SIZE, the problem is still there. The problem is Cygwin will not work with JIT_PAGE_SIZE = 4096. Please have a look at the code I posted. It will always error with "Unable to mprotect".
> 
> 
> The Linux man page for mprotect says that the address MUST be aligned
> (with the systems PAGE_SIZE). Your call to posix_memalign is NOT
> aligning the allocation with the systems PAGE_SIZE (65536), but with
> your PAGE_SIZE (4096).
> 
> You need to allocate memory that is aligned with the systems PAGE_SIZE.
> 
> Eg.
> if(posix_memalign((void**)&buffer, (PAGE_SIZE>JIT_PAGE_SIZE) ? PAGE_SIZE
> 
> : JIT_PAGE_SIZE, available)) { ... }
> 
> --
> Problem reports: https://cygwin.com/problems.html
> FAQ: https://cygwin.com/faq/
> Documentation: https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[-- Attachment #2: OpenPGP_0x473CD05C78734E49.asc --]
[-- Type: application/pgp-keys, Size: 2444 bytes --]

[-- Attachment #3: OpenPGP_signature.sig --]
[-- Type: application/octet-stream, Size: 444 bytes --]

Re: Fw: Re: Fw: Re: Why do these mprotect always fail?

[Corinna Vinschen]

On Feb 15 15:31, w6b7rk5yu4mt25v3 via Cygwin wrote:
> I asked the developer of the interpreter. He said it's OK to use the PAGE_SIZE value different than 4096. So I used this dirty hack:
> 
> #ifndef __CYGWIN__
> #define PAGE_SIZE 4096
> #endif
> 
> This means on Cygwin it will use the default PAGE_SIZE defined on limits.h (I'm taking advantage of the naming conflict here so I don't have to rename PAGE_SIZE to JIT_PAGE_SIZE as suggested by the developer of the interpreter).
> 
> The result is it's no longer error with "Unable to mprotect" but will
> silently crashed without any error messages printed on the screen. So
> after all, it's Cygwin's quirks here.

I still think it's a bug in the code which requires some debugging effort
on your side.

Having said that, if it's actually a Cygwin bug and you want it fixed,
please provide a *simple*, self-contained testcase in plain C, with a
minimum of code to reproduce the issue, and which compiles OOTB.


Corinna

RE: [EXTERNAL] Re: Fw: Re: Fw: Re: Why do these mprotect always fail?

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> I still think it's a bug in the code which requires some debugging effort
> on your side.

I think that OP does not understand that the page size constant is a property of the platform, and not something that can be redefined at will even though it's a macro.

> > #ifndef __CYGWIN__
> > #define PAGE_SIZE 4096
> > #endif

If anything, IMO the conditional should look like:

#ifndef PAGE_SIZE
#define PAGE_SIZE 4096
#endif

and only used after all necessary headers that might define PAGE_SIZE on a particular platform (or all platforms that the code is supposed to be run on), have been already included.

$.02

Anton Lavrentiev
Contractor NIH/NLM/NCBI

> -----Original Message-----
> From: Cygwin <cygwin-bounces+lavr=ncbi.nlm.nih.gov@cygwin.com> On Behalf Of Corinna
> Vinschen via Cygwin
> Sent: Wednesday, February 15, 2023 11:33 AM
> To: w6b7rk5yu4mt25v3 <w6b7rk5yu4mt25v3@protonmail.com>
> Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>; cygwin@cygwin.com
> Subject: [EXTERNAL] Re: Fw: Re: Fw: Re: Why do these mprotect always fail?
> 
> On Feb 15 15:31, w6b7rk5yu4mt25v3 via Cygwin wrote:
> > I asked the developer of the interpreter. He said it's OK to use the PAGE_SIZE value
> different than 4096. So I used this dirty hack:
> >
> > #ifndef __CYGWIN__
> > #define PAGE_SIZE 4096
> > #endif
> >
> > This means on Cygwin it will use the default PAGE_SIZE defined on limits.h (I'm taking
> advantage of the naming conflict here so I don't have to rename PAGE_SIZE to JIT_PAGE_SIZE
> as suggested by the developer of the interpreter).
> >
> > The result is it's no longer error with "Unable to mprotect" but will
> > silently crashed without any error messages printed on the screen. So
> > after all, it's Cygwin's quirks here.
> 
> I still think it's a bug in the code which requires some debugging effort
> on your side.
> 
> Having said that, if it's actually a Cygwin bug and you want it fixed,
> please provide a *simple*, self-contained testcase in plain C, with a
> minimum of code to reproduce the issue, and which compiles OOTB.
> 
> 
> Corinna
> 
> --
> Problem reports:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fproblems.ht
> ml&data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7C123073164bd640013e1b08db0f7270d6%7C14b77578977
> 342d58507251ca2dc2b06%7C0%7C0%7C638120756411216141%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xGvkoh2uUrmyDUWi
> GeWSvPK9FUOclLRDeAzj0Omb7tM%3D&reserved=0
> FAQ:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Ffaq%2F&data
> =05%7C01%7Clavr%40ncbi.nlm.nih.gov%7C123073164bd640013e1b08db0f7270d6%7C14b77578977342d585
> 07251ca2dc2b06%7C0%7C0%7C638120756411216141%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A0S3Y%2FH3SplYCgZyvLJGS
> SNLefPZ9w%2FG%2FC0yMbZbU7g%3D&reserved=0
> Documentation:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fdocs.html&d
> ata=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7C123073164bd640013e1b08db0f7270d6%7C14b77578977342d
> 58507251ca2dc2b06%7C0%7C0%7C638120756411216141%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EOWoOQyBbNc0QxaF1%2B
> kcmgHHwHsPEEvuXTnzV1gdh34%3D&reserved=0
> Unsubscribe info:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fml%2F%23uns
> ubscribe-
> simple&data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7C123073164bd640013e1b08db0f7270d6%7C14b7757
> 8977342d58507251ca2dc2b06%7C0%7C0%7C638120756411216141%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5lX8vOlyCMW6
> 4rxLXtdKPHs6thdr9sB5VlyRZw8MNKY%3D&reserved=0
> CAUTION: This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and are confident the content is safe.

Re: Fw: Re: Fw: Re: Why do these mprotect always fail?

[w6b7rk5yu4mt25v3]

See strace:

544091  601347 [main] obr 1831 mprotect: mprotect (addr: 0xA00100000, len 65536, prot 0x7)
   59  601406 [main] obr 1831 mprotect: 0 = mprotect ()
  166  601572 [main] obr 1831 mmap: addr 0x0, len 327680, prot 0x3, flags 0x22, fd -1, off 0x0
  123  601695 [main] obr 1831 mmap: 0x6FFFFFFB0000 = mmap()
   95  601790 [main] obr 1831 mprotect: mprotect (addr: 0x6FFFFFFC0000, len 196608, prot 0x7)
   88  601878 [main] obr 1831 mprotect: 0 = mprotect ()
  255  602133 [main] obr 1831 mmap: addr 0x0, len 393216, prot 0x3, flags 0x22, fd -1, off 0x0
  102  602235 [main] obr 1831 mmap: 0x6FFFFFF50000 = mmap()
  108  602343 [main] obr 1831 mprotect: mprotect (addr: 0x6FFFFFF60000, len 262144, prot 0x7)
   47  602390 [main] obr 1831 mprotect: 0 = mprotect ()
  245  602635 [main] obr 1831 mmap: addr 0x0, len 458752, prot 0x3, flags 0x22, fd -1, off 0x0
   44  602679 [main] obr 1831 mmap: 0x6FFFFFEE0000 = mmap()
   46  602725 [main] obr 1831 mprotect: mprotect (addr: 0x6FFFFFEF0000, len 327680, prot 0x7)
   39  602764 [main] obr 1831 mprotect: 0 = mprotect ()
--- Process 3796 (pid: 1831), exception c0000005 at 0000000a00100061
--- Process 3796 (pid: 1831) thread 2928 exited with status 0xc0000005
--- Process 3796 (pid: 1831) exited with status 0xc0000005
Segmentation fault

I still think it's Cygwin's bug.

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, February 15th, 2023 at 23:33, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:


> On Feb 15 15:31, w6b7rk5yu4mt25v3 via Cygwin wrote:
> 
> > I asked the developer of the interpreter. He said it's OK to use the PAGE_SIZE value different than 4096. So I used this dirty hack:
> > 
> > #ifndef CYGWIN
> > #define PAGE_SIZE 4096
> > #endif
> > 
> > This means on Cygwin it will use the default PAGE_SIZE defined on limits.h (I'm taking advantage of the naming conflict here so I don't have to rename PAGE_SIZE to JIT_PAGE_SIZE as suggested by the developer of the interpreter).
> > 
> > The result is it's no longer error with "Unable to mprotect" but will
> > silently crashed without any error messages printed on the screen. So
> > after all, it's Cygwin's quirks here.
> 
> 
> I still think it's a bug in the code which requires some debugging effort
> on your side.
> 
> Having said that, if it's actually a Cygwin bug and you want it fixed,
> please provide a simple, self-contained testcase in plain C, with a
> minimum of code to reproduce the issue, and which compiles OOTB.
> 
> 
> Corinna

Fw: Re: Fw: Re: Fw: Re: Why do these mprotect always fail?

[w6b7rk5yu4mt25v3]

Please have a look at the strace result. I still think it's Cygwin's bug.

Sent with Proton Mail secure email.

------- Forwarded Message -------
From: w6b7rk5yu4mt25v3 <w6b7rk5yu4mt25v3@protonmail.com>
Date: On Sunday, February 19th, 2023 at 20:08
Subject: Re: Fw: Re: Fw: Re: Why do these mprotect always fail?
To: cygwin@cygwin.com <cygwin@cygwin.com>


> See strace:
> 
> 544091 601347 [main] obr 1831 mprotect: mprotect (addr: 0xA00100000, len 65536, prot 0x7)
> 59 601406 [main] obr 1831 mprotect: 0 = mprotect ()
> 166 601572 [main] obr 1831 mmap: addr 0x0, len 327680, prot 0x3, flags 0x22, fd -1, off 0x0
> 123 601695 [main] obr 1831 mmap: 0x6FFFFFFB0000 = mmap()
> 95 601790 [main] obr 1831 mprotect: mprotect (addr: 0x6FFFFFFC0000, len 196608, prot 0x7)
> 88 601878 [main] obr 1831 mprotect: 0 = mprotect ()
> 255 602133 [main] obr 1831 mmap: addr 0x0, len 393216, prot 0x3, flags 0x22, fd -1, off 0x0
> 102 602235 [main] obr 1831 mmap: 0x6FFFFFF50000 = mmap()
> 108 602343 [main] obr 1831 mprotect: mprotect (addr: 0x6FFFFFF60000, len 262144, prot 0x7)
> 47 602390 [main] obr 1831 mprotect: 0 = mprotect ()
> 245 602635 [main] obr 1831 mmap: addr 0x0, len 458752, prot 0x3, flags 0x22, fd -1, off 0x0
> 44 602679 [main] obr 1831 mmap: 0x6FFFFFEE0000 = mmap()
> 46 602725 [main] obr 1831 mprotect: mprotect (addr: 0x6FFFFFEF0000, len 327680, prot 0x7)
> 39 602764 [main] obr 1831 mprotect: 0 = mprotect ()
> --- Process 3796 (pid: 1831), exception c0000005 at 0000000a00100061
> --- Process 3796 (pid: 1831) thread 2928 exited with status 0xc0000005
> --- Process 3796 (pid: 1831) exited with status 0xc0000005
> Segmentation fault
> 
> I still think it's Cygwin's bug.
> 
> Sent with Proton Mail secure email.
> 
> 
> ------- Original Message -------
> On Wednesday, February 15th, 2023 at 23:33, Corinna Vinschen corinna-cygwin@cygwin.com wrote:
> 
> 
> 
> > On Feb 15 15:31, w6b7rk5yu4mt25v3 via Cygwin wrote:
> > 
> > > I asked the developer of the interpreter. He said it's OK to use the PAGE_SIZE value different than 4096. So I used this dirty hack:
> > > 
> > > #ifndef CYGWIN
> > > #define PAGE_SIZE 4096
> > > #endif
> > > 
> > > This means on Cygwin it will use the default PAGE_SIZE defined on limits.h (I'm taking advantage of the naming conflict here so I don't have to rename PAGE_SIZE to JIT_PAGE_SIZE as suggested by the developer of the interpreter).
> > > 
> > > The result is it's no longer error with "Unable to mprotect" but will
> > > silently crashed without any error messages printed on the screen. So
> > > after all, it's Cygwin's quirks here.
> > 
> > I still think it's a bug in the code which requires some debugging effort
> > on your side.
> > 
> > Having said that, if it's actually a Cygwin bug and you want it fixed,
> > please provide a simple, self-contained testcase in plain C, with a
> > minimum of code to reproduce the issue, and which compiles OOTB.
> > 
> > Corinna