php memory errors
I've recently gotten out of memory errors with php, with tasks that previously have worked fine. Has anybody else experienced this too? -- 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: unable to run httpd with mod_rewrite
On 26/02/2019 10:30, jwang25...@gmail.com wrote: Hi Richard, Would you please shed some light on this (how to set the mutx for the rewrite map) as I am having the same issue? Thanks a lot in advance James My bad. I didn't check the error logs. Setting the mutex for the rewrite map in the conf file fixed it. On Mon, Oct 15, 2018 at 4:24 PM Richard Lee wrote: I can run httpd when mod_rewrite is disbaled in httpd.conf. When I _ Sent from http://cygwin.1069669.n5.nabble.com Mutex posixsem rewrite-map -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: inotify?
On 03/05/2018 10:35, Ulli Horlacher wrote: Is there a similar service "tell me of new files in this directory tree" in Windows which I can use instead? Windows does have its own file and directory watching API. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: msmtp depends on Gnome!?
On 28/03/2018 22:50, Stephen Paul Carrier wrote: What's not light-weight is its dependency on libgnome-keyring0 which has more dependencies that eventually bring in Gnome. This is for a headless workstation. Gnome doesn't just contain the desktop libraries, it also contains the libraries for gobject. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trouble running ssh-host-config
On 01/03/2018 04:06, Steve Kelem wrote: When I right-click cygwin.bat and run as Administrator, ssh-host-config -y gets the following errors: What happens if you try running cygwin as admin by running mintty as administrator (as opposed to cygwin.bat)? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Git status delay
On 21/11/2017 10:27, Adam Dinwoodie wrote:
(I believe this is a bug in Git, on the grounds that (a) Git in general
supports POSIX systems and giving special meaning to paths starting with
`\\` is allowed, if unusual, POSIX behaviour, and (b) Git specifically
supports Cygwin, and this is very well documented Cygwin behaviour.)
I updated Cygwin and this problem has been fixed. Here's the upstream
commit:
https://github.com/git/git/commit/57dd3dd28724a150e6c6d4c1c8363e1efd49c197.patch
What happened previously was that when is_git_directory("/") was called,
git blindly appended "/HEAD" to the path, causing "//HEAD" (i.e. a
network share) to be lstatted. The commit fixes this by only appending
the '/' before "HEAD" only if it does not end in it already. Hence
"/HEAD" is now lstatted as it should be.
In the name of being able to report this usefully upstream (and ideally
being able to reproduce it myself) can you give me a bit more
information about your environment?
I think the reason why so few people experienced this issue was that
certain people have ISPs that use DNS hijacking. This is where
non-existent DNS names are resolved to a catch-all IP address. They do
this to monetise domain name typos. E.g. if someone mistypes the DNS
part of the URL, the ISP's "not found" page will display adverts based
upon terms extracted from the URL.
So if you lstat("//HEAD") and you are on a network that does DNS
hijacking, Cygwin will attempt to connect to the ISP's server via SMB.
As the ISP's server is a publicly facing IP address, it probably just
black holes any incoming connection requests. So instead of receiving an
immediate connection refusal, the TCP connection request just times out.
This timeout was the cause of the delay.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cryptic characters at 4kboundary after ssh transfer
On 08/12/2017 13:39, Caduff Claudio DFRKSTA wrote: In some (about 1 of 100) of the transferred files there are cryptic characters (always 8 Bytes), always at an address which begins after 4k. Could this be related to any mmap calls? Cygwin mmaps in 4k blocks, but the caveat is that they are aligned at 64k boundaries. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Git status delay
Can also confirm this on Windows 10. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Git status delay
I have an issue with git where it hangs for 10 to 20 seconds on several commands, including "git status". For me this is reproducible on a fresh install of Cygwin x64 in Windows 7. I get the feeling I am doing something wrong on my end as "git status" is a very commonly used command, yet I see no mentions of this on the Cygwin mailing list. Using gdb I can see git hang in the function validate_headref on an lstat call. validate_headref pretty much does what it says and validates the HEAD reference file. validate_headref is called multiple times for different candidate paths for the HEAD reference file, e.g. ".git/HEAD" etc. For some reason the path "//HEAD" is checked and this is causing a delay. Paths starting with "//" are treated in Cygwin as CIFS paths and the delay comes from the timeout when Windows tries to resolve the hostname "HEAD" to a server. Subsequent executions of "git status" return immediately as I guess the resolution of "HEAD" as a hostname is cached. I don't recall having this problem previously. Does anyone else experience this issue? Richard -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ATTN: Yaakov Selkowitz / PHP maintainer] Re: Composer segfault on multiple configurations
Yaakov, I probably should have copied you in on the last message to get your attention. It's just a simple patch to fix this page size issue with php on Cygwin. Would be grateful if you could review and possibly accept this patch, as it has been confirmed and does affect several people. Richard diff --git a/Zend/zend_stream.c b/Zend/zend_stream.c index 3fd7fa0..f5b9bea 100644 --- a/Zend/zend_stream.c +++ b/Zend/zend_stream.c @@ -30,7 +30,11 @@ # if HAVE_UNISTD_H # include # if defined(_SC_PAGESIZE) +# ifdef __CYGWIN__ +#define REAL_PAGE_SIZE 4096 +# else #define REAL_PAGE_SIZE sysconf(_SC_PAGESIZE); +# endif # elif defined(_SC_PAGE_SIZE) #define REAL_PAGE_SIZE sysconf(_SC_PAGE_SIZE); # endif diff --git a/main/main.c b/main/main.c index 01ed3a6..0909309 100644 --- a/main/main.c +++ b/main/main.c @@ -96,7 +96,11 @@ # if HAVE_UNISTD_H # include # if defined(_SC_PAGESIZE) +# ifdef __CYGWIN__ +#define REAL_PAGE_SIZE 4096 +# else #define REAL_PAGE_SIZE sysconf(_SC_PAGESIZE); +# endif # elif defined(_SC_PAGE_SIZE) #define REAL_PAGE_SIZE sysconf(_SC_PAGE_SIZE); # endif -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Memcache/d (Orig: Re: Composer segfault on multiple configurations)
On 25/05/2017 08:50, Sky Diver wrote: Since then I went back in time and installed PHP 5.5.9, PHP 5.6.20 but the result is the same. PHP 5.5.9, PHP 5.6.2 on Cygwin? Were they even released on Cygwin? So I might end up following your steps in order to build PHP, hoping I could enable built-in memcache support while at it (Bash on Ubuntu on Windows, for example, has memcache and memcached included out of the box). Unfortunately, I think memcache is a separate package from php and it would not be compiled in by cygports. From what I read memcache is rather unmaintained and should be deprecated. Memcached should be used instead. https://github.com/oerdnj/deb.sury.org/issues/186#issuecomment-186217296 Memcache can't really be compiled for php7. Memcached can be. Taking a quick look at memcached, the memcached server compiles fine on cygwin except for one minor printf statement. Libmemcached, which php-memcached relies upon, requires a little bit more work (it's that whole "undefined symbols in shared libraries" thing). You possibly may want to consider moving your code from memcache to memcached. For most websites memcache/d is optional. If the website detects that memcache/d is not present during setup, it simply does not use it. Usually people just don't use it for development and then turn it on for production. That is unless you specifically want to run memcache/d code on Cygwin. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Composer segfault on multiple configurations
On 18/05/2017 08:42, Sky Diver wrote: I may compile php from cygports Just in case Sky Diver or anyone else is interested in compiling php from Cygports, here are some simple steps to do so. It's not really difficult and most of the time it takes up is downloading the packages and compiling php. You'll probably want to do the compilation step during a lunch break or something. If you just want to get a patched php running, just skip to the steps below. But I'm also putting putting these instructions out here in case anyone wants to do some testing. The php devs asked for confirmation that (a) the bug exists and (b) this patch actually fixes it, before committing the patch. The devs ask this as they have had problems setting up a dev environment for php. So they are unable recreate this bug or test the patch themselves. This is why I feel any Cygwin-specific patches for php should, for the moment be submitted to Cygwin rather than going to php. To recreate the bug, create a 4096 bytes php file. $ for i in $(seq 4096); do echo; done > test.php Then execute it. $ php test.php This should immediately segfault. You can also test it through apache as there are two ways this bug can occur, through the php cli and through the apache php module. That is why the patch is against two different points in the source. By running apache in debug mode, you can see when the segfault occurs. $ /usr/sbin/apachectl -X Steps = 1. Install the php source from cygwin Install php from the Cygwin installer as normal, except check the Src checkbox as well as the Bin checkbox. 2. cd into the source directory $ cd /usr/src/php-7.0.19-1.src 3. Copy the attachments over in that directory - dependencies - php-7.0.19-page-size.patch - php-cygport-page-size.patch 5. Install the dependencies There are 59 packages required to build php with cygport, listed in the attachment "dependencies". You'll probably use the command line for this rather than manually pick out the packages by hand in Cygwin's setup. You can either use setup's command line -P option or apt-cyg. I used apt-cyg, so for me I run: $ xargs apt-cyg install < dependencies It will take a while to download all these packages. 4. Patch the cygport file $ patch < php-cygport-page-size.patch 6. Prepare the source for compilation $ cygport php.cygport prep 7. Compile php $ cygport php.cygport compile Depending on your cpu, this will take a significant amount of time. 8. Install your compiled php into a staging directory $ cygport php.cygport install 9. Copy the files over from staging into root $ rsync -varlI php-7.0.19-1.x86_64/inst/. / 10. Rebase the dlls in cygwin $ rebase-trigger full Exit all Cygwin processes, command line and services. Run Cygwin's setup to actually perform the rebase. If you rerun "php test.php" you now should get 4096 newlines instead of a segfault. Should the patch miss php 7.0.20 or whatever the next version of php is for Cygwin, you can rerun the steps and just change the path names in steps 2 and 9. But hopefully the path will be merged in by then. diff --git a/Zend/zend_stream.c b/Zend/zend_stream.c index 3fd7fa0..f5b9bea 100644 --- a/Zend/zend_stream.c +++ b/Zend/zend_stream.c @@ -30,7 +30,11 @@ # if HAVE_UNISTD_H # include # if defined(_SC_PAGESIZE) +# ifdef __CYGWIN__ +#define REAL_PAGE_SIZE 4096 +# else #define REAL_PAGE_SIZE sysconf(_SC_PAGESIZE); +# endif # elif defined(_SC_PAGE_SIZE) #define REAL_PAGE_SIZE sysconf(_SC_PAGE_SIZE); # endif diff --git a/main/main.c b/main/main.c index 01ed3a6..0909309 100644 --- a/main/main.c +++ b/main/main.c @@ -96,7 +96,11 @@ # if HAVE_UNISTD_H # include # if defined(_SC_PAGESIZE) +# ifdef __CYGWIN__ +#define REAL_PAGE_SIZE 4096 +# else #define REAL_PAGE_SIZE sysconf(_SC_PAGESIZE); +# endif # elif defined(_SC_PAGE_SIZE) #define REAL_PAGE_SIZE sysconf(_SC_PAGE_SIZE); # endif --- php.cygport 2017-05-14 09:27:04.0 +0100 +++ php-new.cygport 2017-05-20 18:18:45.937823600 +0100 @@ -35,6 +35,7 @@ 5.6.6-fix-libtoolize.patch 5.6.9-apache2handler-zts.patch 7.0.17-pcre-jit-off.patch + php-7.0.19-page-size.patch " DIFF_EXCLUDES="aclocal.m4 configure generated_lists libtool.m4 lt*.m4 ltmain.sh php_config.h.in php_version.h tests" apache2-devel c-client cygport libaspell-devel libattr-devel libcroco0.6-devel libcurl-devel libedit-devel libenchant-devel libfam-devel libffi-devel libgd-devel libgdbm-devel libglapi-devel libgnutls-devel libgs-devel libgtk2.0-devel libgts-devel libguile1.8-devel libguile2.0-devel libgvc-devel libhunspell-devel libicu-devel libidn2-devel libisl-devel libjasper-devel libkrb5-devel libLASi-devel liblcms-devel libllvm-devel liblzo2-devel libmcrypt-devel libming-devel libmpc-devel libmpfr-devel libnghttp2-devel libnss-devel libonig-devel libopenjp2-devel libopenjpeg-devel libpng12-devel libpoppler-devel libpq-devel libpsl-devel libreadline-dev
Re: ANSI colors not showing by default
On 21/05/2017 21:45, Sky Diver wrote: Lately I noticed that colors are not showing by default in some situations. The most apparent case is when running composer. The latest composer version on "Bash on Ubuntu on Windows" console, and even when running it via a mintty shell looks just fine. But from cygwin the output is monochrome. It appears you needs to install the php-posix package to get termcap info. https://serverfault.com/questions/591105/centos-colors-in-php-cli-applications#comment-698025 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 5 seconds to update link info?
On 20/05/2017 01:39, Andrey Repin wrote: I've tried to disable NetBIOS over TCP/IP on client for all adapters active, but nothing has changed. You could always try using Wireshark to get more insight as to what is causing the delay. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 5 seconds to update link info?
On 19/05/2017 23:01, Richard H Lee wrote: On 19/05/2017 22:37, Andrey Repin wrote: When executed this oneliner over Samba 4.3 network share, it takes 5 seconds to match the newly created hardlink. I'm wondering if this is Cygwin, Samba or Windows networking issue? I think it's something to do with windows name resolution. Try running: ls // You should see a similar delay. I forgot to mention that you can get rid of this delay by disabling NetBIOS on your active network connection(s). I don't think this should interfere with the operation of Samba. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 5 seconds to update link info?
On 19/05/2017 22:37, Andrey Repin wrote: When executed this oneliner over Samba 4.3 network share, it takes 5 seconds to match the newly created hardlink. I'm wondering if this is Cygwin, Samba or Windows networking issue? I think it's something to do with windows name resolution. Try running: ls // You should see a similar delay. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ATTN: Yaakov Selkowitz / PHP maintainer] Re: Composer segfault on multiple configurations
On 18/05/2017 08:42, Sky Diver wrote: Any idea when your fix will get released as an official cygwin PHP package? Hi Yaakov, I can see you're really busy with package maintenance and all, but I was wondering if you could review and merge my patch for this issue. It's basically changing the definition of the page size in two places. Richard diff --git a/Zend/zend_stream.c b/Zend/zend_stream.c index 3fd7fa0..f5b9bea 100644 --- a/Zend/zend_stream.c +++ b/Zend/zend_stream.c @@ -30,7 +30,11 @@ # if HAVE_UNISTD_H # include # if defined(_SC_PAGESIZE) +# ifdef __CYGWIN__ +#define REAL_PAGE_SIZE 4096 +# else #define REAL_PAGE_SIZE sysconf(_SC_PAGESIZE); +# endif # elif defined(_SC_PAGE_SIZE) #define REAL_PAGE_SIZE sysconf(_SC_PAGE_SIZE); # endif diff --git a/main/main.c b/main/main.c index 01ed3a6..0909309 100644 --- a/main/main.c +++ b/main/main.c @@ -96,7 +96,11 @@ # if HAVE_UNISTD_H # include # if defined(_SC_PAGESIZE) +# ifdef __CYGWIN__ +#define REAL_PAGE_SIZE 4096 +# else #define REAL_PAGE_SIZE sysconf(_SC_PAGESIZE); +# endif # elif defined(_SC_PAGE_SIZE) #define REAL_PAGE_SIZE sysconf(_SC_PAGE_SIZE); # endif -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Composer segfault on multiple configurations
On 18/05/2017 13:34, Andrey Repin wrote: Try turning pcre.jit off, it was known to be a problem in the past. This is already turned off in the cygport patches. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Composer segfault on multiple configurations
On 17/05/2017 20:17, Sky Diver wrote:
Running "composer install" with the following composer.json ends up in
a segmentation fault.
-- START ---
{
"require": {
"propel/propel": "~2.0@dev"
},
"config": {
"optimize-autoloader": true
}
}
-- END -
(*) Note: when "optimize-autoloader" is set to false the error doesn't occur.
I think this may be to do with the 4096 error bug.
Composer will pull in the files and run them. One of them is:
vendor/propel/propel/src/Propel/Runtime/DataFetcher/PDODataFetcher.php
From you project directory, try running:
php vendor/propel/propel/src/Propel/Runtime/DataFetcher/PDODataFetcher.php
That probably will give you a segfault. I'm not sure if changing the
filesize will help, because composer probably will fetch a fresh copy of
the file.
I did provide a small patch a few weeks ago. That might help. You'd need
to recompile and install php though cygports to use it.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: BUG: winmain GetCommandLine only returning program name and path with no arguments
It works when using the mingw cross compiler.
On 13/05/2017 15:30, Mike Barry wrote:
Below is a sample program that demonstrates that the GetCommandLine
function is not returning the command line arguments. I attached
cygcheck.out.
#include
#include
int WINAPI
WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR szCmdLine, int sw) {
char* text = GetCommandLine();
printf("getcmdline: %s\n", text);
return 0;
}
gcc test_wmain.c -o test
$ ./test hello world
getcmdline: "C:\cygwin64\home\mbarry\game-repos\greenbeam\src\test.exe"
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: hdparm windows phisical disks question
What does ls /dev/hd* or ls /dev/sd* give you? On 11/05/2017 16:21, Emanuele Belfiore wrote: I'm using hdparm on windows, eg: hdparm -y /dev/hda My question is: if I have more than 26 phisical disks, what parameter I have to pass (/dev/hd?) ? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ATTN: PHP maintainer] Re: Fix for REAL_PAGE_SIZE in PHP
Here is my proposed patch for this bug: diff --git a/Zend/zend_stream.c b/Zend/zend_stream.c index 3fd7fa0..f5b9bea 100644 --- a/Zend/zend_stream.c +++ b/Zend/zend_stream.c @@ -30,7 +30,11 @@ # if HAVE_UNISTD_H # include # if defined(_SC_PAGESIZE) +# ifdef __CYGWIN__ +#define REAL_PAGE_SIZE 4096 +# else #define REAL_PAGE_SIZE sysconf(_SC_PAGESIZE); +# endif # elif defined(_SC_PAGE_SIZE) #define REAL_PAGE_SIZE sysconf(_SC_PAGE_SIZE); # endif diff --git a/main/main.c b/main/main.c index 01ed3a6..0909309 100644 --- a/main/main.c +++ b/main/main.c @@ -96,7 +96,11 @@ # if HAVE_UNISTD_H # include # if defined(_SC_PAGESIZE) +# ifdef __CYGWIN__ +#define REAL_PAGE_SIZE 4096 +# else #define REAL_PAGE_SIZE sysconf(_SC_PAGESIZE); +# endif # elif defined(_SC_PAGE_SIZE) #define REAL_PAGE_SIZE sysconf(_SC_PAGE_SIZE); # endif This definition needs to be fixed in two places as there are two different places where a PHP source file can be mmap()ed, depending on whether it is loaded using php-cli or loaded when php is run from a library. On 02/05/2017 11:28, Richard H Lee wrote: Should this fix go upstream to PHP or be submitted to the PHP package within Cygwin? I ask this as partially accessibly memory pages I guess are a quirk of Cygwin. But then again programs ideally should not read past the end of the EOF in the region the file is mmap()ed to. Richard -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Fix for REAL_PAGE_SIZE in PHP
There is a bug with PHP on Cygwin where it segfaults if the php file size is a multiple of 4K. https://bugs.php.net/bug.php?id=65312 PHP mmap()s source files as it it faster than using normal I/O. The problem is with the page size in Cygwin. When a file is mmap()ed to memory, any remaining bytes after the EOF in the last page are zero'ed out. So when PHP reads the bytes after the EOF, it expects to find zeroes. In most systems the page size is 4K. In Windows the page size is also 4K, but aligned to a boundary of 64K (allocation granularity). Cygwin reconciles this by making the page size 64K. So in reality, Cygwin pages are 64K big, backed by 4K pages allocated along 64K boundaries. When PHP reads a file, it looks at the file size. If there are enough bytes to read ahead in the last memory page after the EOF, PHP will use mmap. Else it will open the file normally. When PHP is given a 4K file on Cygwin, it sees that the file and the bytes for reading ahead will easily fit into a 64K page (in Cygwin). So it mmap()s the file. However only one 4K page (in Windows) is mapped to. The remaining 60K pages are not. When PHP reads ahead past the EOF, it reads into page which has not been mapped to. This results in a segfault. Changing the REAL_PAGE_SIZE to 4096 fixes the issue. Should this fix go upstream to PHP or be submitted to the PHP package within Cygwin? Richard -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Basic gcc compilation on cygwin64
On 23/07/2013 13:35, JonY wrote: Try rerunning setup again, there was a mistake in the w32api-runtime -1 release. -2 should have this fixed. Yeah, I just installed xxd 5 mins ago and I saw w32api-runtime flash up on the download bar. I figured that was the package and gave gcc another shot. It compiles fine now. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Basic gcc compilation on cygwin64
I'm trying to compile the following basic program on cygwin64:
int main() {
;
return 0;
}
But I get the following errors:
$ gcc test.c
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -ladvapi32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lshell32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -luser32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lkernel32
collect2: error: ld returned 1 exit status
This is my first time using the 64-bit version of cygwin and I get the
feeling I am missing some sort of flag or library.
Richard
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Phantom processes left over
Has anybody come across processes being left over? I'm extending an open source project. The functionality I'm adding is keeping track of running processes. I store the list of active processes in shared memory. When querying the list I also call kill with a 0 signal on all the entries to test if they are still running. The problem is that when a process has clearly ended, by this I mean it does on show up in cygwin's ps or window's task manager, calling kill with signal 0 still returns 0. The same for calling "kill -s 0 " from the command line. This indicates that supposedly the process is still running. Also the pid is still present in the /proc filesystem. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Persistence of file implemented objects
Fifos persist on reboot on Linux or Cygwin. They live on the filesystem. I don't see how POSIX IPC shared memory and semaphores could persist. Sorry, I meant unix/bsd sockets. Regarding the POSIX IPC's, they are stored in /dev . In regular *nix, /dev do not represent "physical" files on the filesystem, hence they do not persist over boot. In cygwin, they actually do represent physical files. So if they are not freed correctly by the program, the persist over to the next boot. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Persistence of file implemented objects
Various objects like fifo pipes, POSIX IPC shared memory and semaphores that are implemented through the filesystem in cygwin persist when the program abnornally terminates. They also persist through reboots, which is different to the behaviour on linux. This is also different with the case of sysV IPC + cygserver on cygwin which clears after reboots. If there anyway to clear out orphaned objects or to make sure they are released in the event of an abnormal termination? Does the POSIX specification even require the release of these objects in these situations? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: FW: gdbserver on cygwin
On 30/06/2012 18:05, Christopher Faylor wrote: On Sat, Jun 30, 2012 at 04:22:03PM +0200, marco atzeri wrote: On 6/30/2012 3:18 PM, Richard H Lee wrote: On 30/06/2012 03:07, Buchbinder, Barry (NIH/NIAID) [E] wrote: >> Is it supported yet? > > http://cygwin.com/packages/ > http://cygwin.com/cgi-bin2/package-grep.cgi?grep=gdbserver But the gdbserver binary is not available from setup.exe . It does however compile and function correctly from source. feel free to offer yourself as package maintainer http://cygwin.com/setup.html Sorry, no. gdbserver is part of gdb. It doesn't require a separate package. But that's the thing, when you mark gdb for installation via setup.exe you only get the gdb executable not the gdbserver executable. Unless I'm doing something wrong here. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: FW: gdbserver on cygwin
On 30/06/2012 03:07, Buchbinder, Barry (NIH/NIAID) [E] wrote: >> Is it supported yet? > > http://cygwin.com/packages/ > http://cygwin.com/cgi-bin2/package-grep.cgi?grep=gdbserver But the gdbserver binary is not available from setup.exe . It does however compile and function correctly from source. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
gdbserver on cygwin
As of 2003 gdbserver was not supported on cygwin. Is it supported yet? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
POSIX or SYSV IPC calls on cygwin
I'm looking to use IPC calls on cygwin (shared memory and semaphores). The posix IPC api looks saner (easier), but it looks like it was only brought in in cygwin 1.7 . Am I better sticking to the SYSV IPC api? Or is the POSIX IPC api stable enough to use? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
