Why do these mprotect always fail?
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.
--
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
Re: Why do these mprotect always fail?
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
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.
--
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
Re: Why do these mprotect always fail?
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 -- 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
Fw: Re: Why do these mprotect always fail?
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 Date: On Wednesday, February 15th, 2023 at 17:32 Subject: Re: Why do these mprotect always fail? To: cygwin@cygwin.com CC: w6b7rk5yu4mt25v3 > 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 -- 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
Re: Fw: Re: Why do these mprotect always fail?
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 -- 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
Re: Fw: Re: Why do these mprotect always fail?
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 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 -- 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
RE: Changing the python sqlite3 version to the latest
On February 14, 2023 8:46 PM, Jose Isaias Cabrera expressed:
>
>
> On Tuesday, February 14, 2023 5:58 PM, Marco Atzeri expressed:
> >
> > On 11.02.2023 22:37, Jose Isaias Cabrera via Cygwin wrote:
> > >
> > > Greetings.
> > >
> > > If I install python39 and thus,
> > > $ python
> > > Python 3.9.10 (main, Jan 20 2022, 21:37:52) [GCC 11.2.0] on cygwin
> > > Type "help", "copyright", "credits" or "license" for more information.
> > import sqlite3
> > sqlite3.sqlite_version
> > > '3.34.0'
> > Last version packaged for Cygwin is 3.34.0
> >
> > Until Jan (or someone else) is packaging a more recent version that is
> > what is available
> >
> > Regards
> > Marco
>
> Yes, but the question is how can I update the SQLite version? I have been
> able to do it with 2 PCs, but there is one that is not able. Some of the
> sqlite folks said that is a DLL issue.
In case anyone needs the answer, These steps worked for me:
-- Downloaded the Pre-release Snapshots
$ wget https://sqlite.org/snapshot/sqlite-snapshot-202302131932.tar.gz
-- untared the snapshot
$ tar xvf sqlite-snapshot-202302131932.tar.gz
-- cd to the untared directory
$ cd sqlite-snapshot-202302131932
$ ./configure --prefix=/usr
$ make install
And this process has set the python SQLite version to the sqlite-snapshot
version. After that, you can download the trunk and follow the same procedure,
and the version of the trunk will be changed also.
$ ./SQLiteVersion.py
3.41.0
['/usr/lib/python3.9/sqlite3']
3.41.0
2023-02-13 19:32:40
ecdeef43b27412b0b0b09e09a62ad3a03836a3fc80f2070268090e7ca8f02712
I hope this helps.
[JIC]
This script may be useful...
$ cat SQLiteVersion.py
#!/usr/bin/python3
import sqlite3
def ConnectToSharedDB(sdb):
return sqlite3.connect(sdb)
print(sqlite3.sqlite_version)
print(sqlite3.__path__)
SharedDB = ":memory:"
con = ConnectToSharedDB(SharedDB)
cur = con.cursor()
cur.execute("SELECT sqlite_version(),sqlite_source_id();")
for row in cur:
print(row[0] + '\r\n' + row[1])
con.close()
--
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
Re: Fw: Re: Why do these mprotect always fail?
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)) { ... }
OpenPGP_0x473CD05C78734E49.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
--
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
Re: Fw: Re: Why do these mprotect always fail?
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 -- 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
Re: [ANNOUNCEMENT] Updated: dash 0.5.12-2
Hi Brian, On Feb 13 20:37, Corinna Vinschen via Cygwin wrote: > On Feb 13 12:03, Brian Inglis via Cygwin wrote: > > On 2023-02-13 10:43, ASSI via Cygwin wrote: > > > Corinna Vinschen via Cygwin writes: > > > > Can you give me an example? I'm a bit puzzled because fnmatch as well > > > > as glob in Cygwin support native characters. > > > > But not locale dependent named character classes like regexp in paths. > > I checked the dash code of curent dash git, and while its internal glob > implementation supports character classes, they are no localized, using > standard singlebyte functions isalnum, isalpha, etc. under the hood. > > So, yeah, what you say further down this mail... looks like dash > supports locale dependent character classes only with glibc. > [...] > Either way, I don't care much for what a certain application provides by > itself. I'm talking about our libc, that is Cygwin, and what it > provides to processes calling its implementations of regcomp/regexec, > glob and fnmatch. > > All these functions have been taken from FreeBSD and all three suffer > shortcomings: > > - regcomp/regexec supports POSIX named character classes, collating > symbols, and equivalence class expressions, but all of them only work > for ASCII chars. > > - fnmatch and glob support neither of named character classes, > collating symbols, and equivalence class expressions. > > I checked the upstream code in FreeBSD, OpenBSD and NetBSD and none of > these functions are improved to support locales (regcomp) or any of > the character classes stuff (fnmatch/glob). > > So, if we want to add this support to Cygwin (and thus, to all > applications calling the libc implementation of these functions), > quite a bit of work is required. > > Being able to fetch the implementation from some other source > would reduce the effort enourmously :} I took the liberty to add [::] support to Cygwin's fnmatch(3) and glob(3) functions. They also recognize collating symbols [.=]. But the latter two are not implemented yet and fnmatch/glob simply skip them in the pattern. Given that glob and fnmatch use wide characters internally, the support for character classes is internationalized by default, albeit in a slightly differentt way than in glibc. The classes a unicode character belongs to is not locale dependent in Cygwin/newlib. All characters have their classes assigned all the time, so, for instance, the german character 'ä' is lower and alpha even in the en_US.utf8 locale. The currently building cygwin test release 3.5.0-0.174.gd6d4436145b8 contains the new code. Would you mind to build a dash for testing so we can see if and how it works? Thanks, Corinna -- 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
Re: [ANNOUNCEMENT] Updated: dash 0.5.12-2
Oh, I'm an idiot.
On Feb 15 14:52, Corinna Vinschen via Cygwin wrote:
> Hi Brian,
> [...]
> The currently building cygwin test release 3.5.0-0.174.gd6d4436145b8
> contains the new code. Would you mind to build a dash for testing so we
> can see if and how it works?
You don't have to build a new dash. Just downgrading to
dash-0.5.12-1 will suffice, of course. D'oh.
So, as a first test, here's the result of Andrey's expression
with dash-0.5.12-1:
$ dash -c '_x=" x"; echo "${_x#${_x%%[![:space:]]*}}"'
x
Corinna
--
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
[ANNOUNCEMENT] Updated: GraphicsMagick-1.3.40-1
Version 1.3.40-1 of GraphicsMagick libGraphicsMagick-devel libGraphicsMagick3 libGraphicsMagick++12 libGraphicsMagickWand2 perl-Graphics-Magick have been uploaded for cygwin CHANGES Upstream security and bug fixes release http://www.graphicsmagick.org/NEWS.html#january-14-2023 DESCRIPTION GraphicsMagick is the swiss army knife of image processing. It provides a robust and efficient collection of tools and libraries which support reading, writing, and manipulating an image in over 88 major formats including important formats like DPX, GIF, JPEG, JPEG-2000, PNG, PDF, PNM, and TIFF. HOMEPAGE http://www.graphicsmagick.org/ Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . -- 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
[ANNOUNCEMENT] Updated: mutt-2.2.9-1
New version 2.2.9-1 of mutt is available in the Cygwin distribution: CHANGES Last upstream bugfix update release. Full details on: https://gitlab.com/muttmua/mutt/raw/master/UPDATING DESCRIPTION The Mutt E-Mail Client "All mail clients suck. This one just sucks less." Mutt is a small but very powerful text-based mail client for Unix operating systems. HOMEPAGE http://www.mutt.org/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . -- 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
Fw: Re: Fw: Re: Why do these mprotect always fail?
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
Date: On Wednesday, February 15th, 2023 at 20:02
Subject: Re: Fw: Re: Why do these mprotect always fail?
To: 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
OpenPGP_0x473CD05C78734E49.asc
Description: application/pgp-keys
OpenPGP_signature.sig
Description: Binary data
--
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
Re: Changing the python sqlite3 version to the latest
Greetings, Jose Isaias Cabrera!
> In case anyone needs the answer, These steps worked for me:
> -- Downloaded the Pre-release Snapshots
> $ wget https://sqlite.org/snapshot/sqlite-snapshot-202302131932.tar.gz
> -- untared the snapshot
> $ tar xvf sqlite-snapshot-202302131932.tar.gz
> -- cd to the untared directory
> $ cd sqlite-snapshot-202302131932
> $ ./configure --prefix=/usr
> $ make install
Don't forget to rebase the resulting binary(-es).
> And this process has set the python SQLite version to the sqlite-snapshot
> version. After that, you can download the trunk and follow the same
> procedure, and the version of the trunk will be changed also.
> $ ./SQLiteVersion.py
> 3.41.0
> ['/usr/lib/python3.9/sqlite3']
> 3.41.0
> 2023-02-13 19:32:40
> ecdeef43b27412b0b0b09e09a62ad3a03836a3fc80f2070268090e7ca8f02712
> I hope this helps.
> [JIC]
> This script may be useful...
> $ cat SQLiteVersion.py
> #!/usr/bin/python3
> import sqlite3
> def ConnectToSharedDB(sdb):
> return sqlite3.connect(sdb)
> print(sqlite3.sqlite_version)
> print(sqlite3.__path__)
> SharedDB = ":memory:"
> con = ConnectToSharedDB(SharedDB)
> cur = con.cursor()
> cur.execute("SELECT sqlite_version(),sqlite_source_id();")
> for row in cur:
> print(row[0] + '\r\n' + row[1])
> con.close()
--
With best regards,
Andrey Repin
Wednesday, February 15, 2023 18:54:24
Sorry for my terrible english...
--
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
Re: [ANNOUNCEMENT] Updated: dash 0.5.12-2
Greetings, Corinna Vinschen via Cygwin!
> On Feb 15 14:52, Corinna Vinschen via Cygwin wrote:
>> Hi Brian,
>> [...]
>> The currently building cygwin test release 3.5.0-0.174.gd6d4436145b8
>> contains the new code. Would you mind to build a dash for testing so we
>> can see if and how it works?
> You don't have to build a new dash. Just downgrading to
> dash-0.5.12-1 will suffice, of course. D'oh.
> So, as a first test, here's the result of Andrey's expression
> with dash-0.5.12-1:
> $ dash -c '_x=" x"; echo "${_x#${_x%%[![:space:]]*}}"'
> x
:thumbsup:
--
With best regards,
Andrey Repin
Wednesday, February 15, 2023 18:56:29
Sorry for my terrible english...
--
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
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://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: [EXTERNAL] Re: Fw: Re: Fw: Re: Why do these mprotect always fail?
> 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 On Behalf Of > Corinna > Vinschen via Cygwin > Sent: Wednesday, February 15, 2023 11:33 AM > To: w6b7rk5yu4mt25v3 > Cc: Corinna Vinschen ; 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. -- 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
Re: Changing the python sqlite3 version to the latest
On Wednesday, February 15, 2023 10:55 AM, Andrey Repin expressed: > > -- untared the snapshot > > $ tar xvf sqlite-snapshot-202302131932.tar.gz > > > -- cd to the untared directory > > $ cd sqlite-snapshot-202302131932 > > > $ ./configure --prefix=/usr > > > $ make install > > Don't forget to rebase the resulting binary(-es). How do I do that? Right now, "it's working ok", from what I can see. Thanks. -- 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
Re: [ANNOUNCEMENT] Updated: dash 0.5.12-2
On 2023-02-15 07:05, Corinna Vinschen via Cygwin wrote:
On Feb 15 14:52, Corinna Vinschen via Cygwin wrote:
The currently building cygwin test release 3.5.0-0.174.gd6d4436145b8
contains the new code. Would you mind to build a dash for testing so we
can see if and how it works?
You don't have to build a new dash. Just downgrading to
dash-0.5.12-1 will suffice, of course. D'oh.
So, as a first test, here's the result of Andrey's expression
with dash-0.5.12-1:
$ dash -c '_x=" x"; echo "${_x#${_x%%[![:space:]]*}}"'
x
Good and quick work!
I was still looking thru my last Cygwin build for the Unicode tables, that I
remember being rebuilt some time ago, and to find what used them, and whether
they were updated to Unicode 15.
I'll install the test Cygwin and old dash, then prep and check a new/old dash
release 3 in test, for release with untest when the Cygwin changes are released,
rather than play with replacing versions and going back and forth.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirerbut when there is no more to cut
-- Antoine de Saint-Exupéry
--
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
[QUERY] Help With Semaphore Error on Windows : Cygwin
Hi All,
Could I request for some help on some code?
I ran into an error with semaphores with some book code using Cygwin on
Windows.
The code will throw an error with sem_post().
I compiled it with gcc -o memwriter memwriter.c -lrt -lpthread
$ ./memwriter
Shared memory address: 0x6fff [0..511]
backing file: /dev/shm/shMemEx
semptr is address 0x7cc18 with value 0
SEM_VALUE_MAX is 1147483648
sem_post: Invalid argument <--- ERROR
According to feedback, the above error does not turn up on Linux.
May I know if this is supposed to happen on Cygwin on Windows?
If not, how can I solve this?
I've also attached the code for reference.
Thank you.
Kind regards,
YEO Kai Wei
#define ByteSize 512
#define BackingFile "/shMemEx"
#define AccessPerms 0644
#define SemaphoreName "mysemaphore"
#define MemContents "This is the way the world ends...\n"
//gcc -o memwriter memwriter.c -lrt -lpthread
#include
#include
#include
#include
#include
#include
#include
#include
#include //SEM_VALUE_MAX
#include "shmem.h"
void report_and_exit(const char* msg)
{
perror(msg);
exit(-1);
}
int main()
{
//Create file descriptor
int fd = shm_open( BackingFile,
O_RDWR | O_CREAT, //Read, write, create
if needed
AccessPerms); //Access permission 0644
//ERROR
if(fd<0)
report_and_exit("Can't open shared mem segment ... ");
//Get the bytes
ftruncate(fd, ByteSize);
//Let system pick where to put the segments
caddr_t memptr = mmap( NULL, //Let system pick
ByteSize, //How many bytes
PROT_READ | PROT_WRITE, //Access protections
MAP_SHARED, //Mapping visible
fd, //file descriptor
0); //offset 0, start from
1st byte
if((caddr_t) -1 == memptr)
report_and_exit("Can't get segment...");
fprintf(stderr, "Shared memory address: %p [0..%d]\n", memptr, ByteSize
-1);
fprintf(stderr, "backing file: /dev/shm%s\n", BackingFile);
//Create the semaphore
sem_t* semptr = sem_open( SemaphoreName,//name
O_CREAT, //create semaphore
AccessPerms, //protection permissions
0); //Initial value
//ERROR
if(semptr == (void*) -1)
report_and_exit("sem_open");
//Copy some ASCII Bytes to the memory segment
strcpy(memptr, MemContents);
printf("semptr is address %p with value %i\n", &semptr, semptr);
printf("SEM_VALUE_MAX is %i\n", SEM_VALUE_MAX);
//sem_post increments the semaphore -1 ERROR, 0 success
if(sem_post(semptr) < 0)
report_and_exit("sem_post");
//Sleep
sleep(12);
//Cleanup. Unmap the storage
munmap(memptr, ByteSize);
close(fd);
sem_close(semptr);
//Unlink from backing file
shm_unlink(BackingFile);
return 0;
}
--
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
Re: Changing the python sqlite3 version to the latest
Greetings, Jose Isaias Cabrera! > On Wednesday, February 15, 2023 10:55 AM, Andrey Repin expressed: >> > -- untared the snapshot >> > $ tar xvf sqlite-snapshot-202302131932.tar.gz >> >> > -- cd to the untared directory >> > $ cd sqlite-snapshot-202302131932 >> >> > $ ./configure --prefix=/usr >> >> > $ make install >> >> Don't forget to rebase the resulting binary(-es). > How do I do that? rebase -s /path/to/binary … The -n switch may be necessary as well. > Right now, "it's working ok", from what I can see. Thanks. Merely a coincidence. -- With best regards, Andrey Repin Thursday, February 16, 2023 02:44:10 Sorry for my terrible english... -- 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
