Re: Windows 8 Release Preview. fork problems with rsync
On Jun 7 10:12, Noel Grandin wrote: > > > On 2012-06-06 20:29, Corinna Vinschen wrote: > > >On Jun 6 17:59, Nick Lowe wrote: > >>>Thanks. I can confirm the effect. For no apparent reason, the OS > >>>reserves a 1 Megs shared memory region, top-down allocated, of which it > >>>uses about 20K. It's not the PEB or one of the TEBs, though. Nor is > >>>it a thread stack. I checked, and it turns out that it's allocated > >>>in every process, on 32 and 64 bit systems. That's kind of worrying > >>>since that's bound to collide with mmaped regions and pthread stacks a > >>>lot. I don't know what to do at this point. > > > > > > I assume you've seem the VMMap tool? > http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx Yes, and I also know how to use /proc/$PID/maps to get a memory map of a process. It's not a problem to see the used memory slot. The problem is that it exists at all. There's no such thing on pre-W8 systems. Only the PEB and the TEBs are allocated top-down and they usually don't collide. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Windows 8 Release Preview. fork problems with rsync
On Jun 7 10:35, Ryan Johnson wrote:
> On 06/06/2012 12:12 PM, Corinna Vinschen wrote:
> >On Jun 6 16:41, Bertrand Latinville wrote:
> >>I'm using
> >>
> >> rsync --chmod=ug=rwX -arvz --prune-empty-dirs --include="*/"
> >>--include-from=include-file.txt --exclude="*" ${source_dir}/
> >>${dest_dir}
> >Thanks. I can confirm the effect. For no apparent reason, the OS
> >reserves a 1 Megs shared memory region, top-down allocated, of which it
> >uses about 20K. It's not the PEB or one of the TEBs, though. Nor is
> >it a thread stack. I checked, and it turns out that it's allocated
> >in every process, on 32 and 64 bit systems. That's kind of worrying
> >since that's bound to collide with mmaped regions and pthread stacks a
> >lot. I don't know what to do at this point.
> Given that the OS always gets there first, why not just adjust
> Cygwin's definition of "top" for win8? Or does heap randomization
> move that mystery chunk around?
Yes, the chunk is moved around. Thousands of tests show a lowest
memory slot, but the problem is that top-down allocation is not a
manual functionality done by Cygwin. It's just a flag in calls
to VirtualAlloc or MapViewOfFileEx. Therefore, if we have to define
our own highest memory slot, it requires Cygwin to do some trickery
on its own, which was just not necessary so far.
I'm going to ask Microsoft about this issue first. Maybe it's
something only in the release preview which will go away in the
gold release. If so, I won't start to workaround it.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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: Trusted Software Vendor
On Jun 14 22:45, Andrey Repin wrote: > Greetings, Vaclav Zeman! > > Out of curiosity would downloading setup.exe using wget also work > around the problem? > >>> > >>>Most likely. I don't think wget cares about protecting Windows users > >>>from their own stupidity. If you use wget, you should know what you're > >>>doing. > >>> > >>>How about you just give it a try? > >> > >> Er, I don't have this problem. I wasn't the one reporting it. > > Downloading setup.exe with wget has another problem. The downloaded > > file is missing the +x bit, IIRC. > > It's irrelevant for setup.exe. It's not. Try to start any executable on a NTFS filesystem. Remove the executable bits from all entries in the ACL. Try again. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Problem with MAP_PRIVATE for fork() using pypy
On Jun 9 17:19, Uwe F. Mayer wrote:
> I have recently patched pypy (http://www.pypy.org) to compile under
> Cygwin. Pypy implements a Python interpreter with a Just In Time (JIT)
> compiler. At runtime pypy uses a MAP_PRIVATE anonymous mmap to
> allocate memory for its JIT. This seems to be cause of fork() calls
> failing. A sample error message is included below. I have discussed
> this problem at length with the pypy developers. The discussion is
> online at:
>
> http://www.mail-archive.com/pypy-dev@python.org/msg02448.html
>
> Finally I hacked the pypy sources and replaced the MAP_PRIVATE
> anonymous mmap allocation with MAP_SHARED at the place where pypy
> allocates its JIT temporary memory, and the code runs fine (but that's
> not a solution for pypy, as their JIT child and parent processes
> likely will drift apart for any real non-toy program and do need
> separate memory space). From what the pypy folks say, this is not a
> pypy issue but a Cygwin issue.
> [...]
> PS Attached is an output of cygcheck, and the relevant portion of an strace.
Unfortunately the "relevant portion" of the strace is not at all relevant
to see what happens. The error message is weird. This should not occur
at all if the memory address still exists in the parent. I can't reproduce
it with a simple testcase (see below) either. I ran it on a 64 bit system
so that the allocated memory area is in the large address area, just as in
your scenario.
If you could create a testcase in plain C which allows to reproduce the
behaviour, it would help a lot to track down the cause.
Corinna
#include
#include
#include
int main ()
{
char *p;
int sz = 2 * getpagesize ();
int offset;
int magic = 0x33;
int pid;
int rv;
p = (char *) mmap (NULL, sz, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
if (p == MAP_FAILED)
{
printf ("mmap() = MAP_FAILED\n");
return 1;
}
printf ("mmap() = %p\n", p);
offset = getpagesize () + 0x42;
p[offset] = magic;
pid = fork ();
switch (pid)
{
case (-1):
printf ("fork() failed\n");
break;
case (0):
printf ("child alive\n");
sleep (1);
printf ("child touching %p\n", &(p[offset]));
printf ("child M[%p] = 0x%x\n", &(p[offset]), p[offset]);
p[offset] = 0x44;
printf ("child M[%p] = 0x%x\n", &(p[offset]), p[offset]);
pid = fork ();
switch (pid)
{
case (-1):
printf ("fork() failed\n");
break;
case (0):
printf ("grandchild alive\n");
sleep (1);
printf ("grandchild touching %p\n", &(p[offset]));
printf ("grandchild M[%p] = 0x%x\n", &(p[offset]), p[offset]);
sleep (2);
printf ("grandchild M[%p] = 0x%x\n", &(p[offset]), p[offset]);
break;
default:
printf ("child alive\n");
sleep (2);
printf ("child touching %p\n", &(p[offset]));
printf ("child M[%p] = 0x%x\n", &(p[offset]), p[offset]);
p[offset] = 0x55;
printf ("child M[%p] = 0x%x\n", &(p[offset]), p[offset]);
break;
}
break;
default:
printf ("parent alive\n");
sleep (5);
printf ("parent touching %p\n", &(p[offset]));
printf ("parent M[%p] = 0x%x\n", &(p[offset]), p[offset]);
break;
}
return 0;
}
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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
sshd connections unexpectedly close on windows 2012
Hi, I'm having problems with running sshd on cygwin on Windows Server 2012 Release Candidate. I installed cygwin and set up sshd, and I am opening ssh connections using a Python script (running Fabric to perform operations on the Windows machine). However there appears to be a problem with sshd and my connections sometimes get closed unexpectedly. I looked in the Event Viewer and found the following log: "The description for Event ID 0 from source sshd cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event. The following information was included with the event: sshd: PID 2860: error: do_exec_pty: fork: Resource temporarily unavailable" I also looked in the sshd log in c:\cygwin\var\log\sshd and found this error message: " 5 [main] sshd 180 fhandler_dev_zero::fixup_mmap_after_fork: requested 0xFEF2 != 0x0 mem alloc base 0x0, state 0x1, size 1179648, Win32 error 487 2833 [main] sshd 180 C:\cygwin\usr\sbin\sshd.exe: *** fatal error in forked process - recreate_mmaps_after_fork_failed 4115 [main] sshd 180 open_stackdumpfile: Dumping stack trace to sshd.exe.stackdump 2 [main] sshd 2396 fork: child -1 - forked process 180 died unexpectedly, retry 0, exit code 256, errno 11" It is not easy to debug this problem because it doesn't happen every time I open an ssh connection but only when I open and close multiple connections subsequently using the Python script. It appears to be random and the script crashes (because of closed connections) at different points every time. I tried following the FAQ suggestions and some suggestions from other threads but I had no luck: I tried running rebaseall with 0x7700 and 0x4000. I tried the latest version of cygwin1.dll. I tried increasing the heap size in the Windows registry. Restarting the process or using retry loops is not an option because the problem persists. The same script and setup work fine on Windows 2003, 2008, 2008R2, and Windows 7. Any idea what might be causing this problem on Windows 2012? Perhaps some memory settings that I'm missing? Thanks Arnon -- 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: sshd connections unexpectedly close on windows 2012
On Jun 18 18:35, Arnon Yaari wrote: > Hi, > I'm having problems with running sshd on cygwin on Windows Server 2012 > Release Candidate. > I installed cygwin and set up sshd, and I am opening ssh connections using a > Python script (running Fabric to perform operations on the Windows machine). > However there appears to be a problem with sshd and my connections sometimes > get closed unexpectedly. > I looked in the Event Viewer and found the following log: > > "The description for Event ID 0 from source sshd cannot be found. Either the > component that raises this event is not installed on your local computer or > the installation is corrupted. You can install or repair the component on the > local computer. > > If the event originated on another computer, the display information had to > be saved with the event. > > The following information was included with the event: > > sshd: PID 2860: error: do_exec_pty: fork: Resource temporarily unavailable" > > I also looked in the sshd log in c:\cygwin\var\log\sshd and found this error > message: > > " 5 [main] sshd 180 fhandler_dev_zero::fixup_mmap_after_fork: requested > 0xFEF2 != 0x0 mem alloc base 0x0, state 0x1, size 1179648, Win32 > error 487 >2833 [main] sshd 180 C:\cygwin\usr\sbin\sshd.exe: *** fatal error in > forked process - recreate_mmaps_after_fork_failed >4115 [main] sshd 180 open_stackdumpfile: Dumping stack trace to > sshd.exe.stackdump > 2 [main] sshd 2396 fork: child -1 - forked process 180 died > unexpectedly, retry 0, exit code 256, errno 11" > > It is not easy to debug this problem because it doesn't happen every > time I open an ssh connection but only when I open and close multiple > connections subsequently using the Python script. This is probably the same problem as reported in the thread starting at http://cygwin.com/ml/cygwin/2012-06/msg00089.html There's no solution yet, sorry. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: MS-DOS-style paths are not recognized in elisp function in 23.4-2
On 6/18/2012 1:40 PM, Neal Groothuis wrote: Hello all, In Emacs 23.4-2 on Cygwin, the byte-compile-file Elisp function does not recognize MS-DOS style paths. E.g., if I call (byte-compile-file "C:/foo/bar.el" t), it will try to compile "/home/ngroothuis/C:/foo/bar.el". This is a problem for those of developing in Clojure, as Leiningen's Swank plugin has Emacs execute an ELisp file in the user's home directory. Since Clojure runs on the JVM, when it reads the HOME environment variable to build the path to the ELisp file, it sees the MS-DOS style path rather than the POSIX-style path. Does the cygpath utility help? Ken -- 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: CYGWIN app crashes ungracefully when run from the root of a drive
On Jun 11 11:39, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > Hi, > > Maybe it has been covered somewhere -- I could not find the answer, so please > excuse the repetition. I observe that if I build an app (consider the > simplest > "Hello world" program below as an example), and store the executable at a > standalone > location (not CYGWIN tree), yet supplemented it with a cygwin1.dll, it can > then successfully > run when started in the Windows shell (CMD.EXE) from a subdirectory, but > fails ungracefully > if run from the root of a drive (e.g. when stored onto a USB stick that has > the "flat" > file structure, w/o subdirectories). > > Can anything be done about it? (Like allowing the app to run, or issuing an > error I just applied a patch which allows to run Cygwin applications, even if the Cygwin DLL is installed into the root directory of a drive or network path. Note that certain paths still have to match the expectations. For instance, if D: is the root dir, the fstab, passwd and group files are still searched in /etc, which is D:\etc. Also the /usr/bin and /usr/lib default mount points will invariably point to D:\bin and D:\lib, unless there's a /etc/fstab file which changes them per the user's guide. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: MS-DOS-style paths are not recognized in elisp function in 23.4-2
On 6/18/2012 2:41 PM, Ken Brown wrote: > Does the cygpath utility help? If emacs can be patched to use it on on file open calls, sure. - Neal -- 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: MS-DOS-style paths are not recognized in elisp function in 23.4-2
On 6/18/2012 4:46 PM, Neal Groothuis wrote: On 6/18/2012 2:41 PM, Ken Brown wrote: Does the cygpath utility help? If emacs can be patched to use it on on file open calls, sure. I was suggesting that you should consider using cygpath to convert your MS-DOS path to a POSIX path. Cygwin programs generally expect POSIX paths, and emacs is no exception. Ken -- 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: sshd connections unexpectedly close on windows 2012
> -Original Message- > Sent: Monday, June 18, 2012 16:34 > Subject: Re: sshd connections unexpectedly close on windows 2012 > > > " 5 [main] sshd 180 fhandler_dev_zero::fixup_mmap_after_fork: > requested 0xFEF2 != 0x0 mem alloc base 0x0, state 0x1, size > 1179648, Win32 error 487 > >2833 [main] sshd 180 C:\cygwin\usr\sbin\sshd.exe: *** fatal error in > forked process - recreate_mmaps_after_fork_failed > >4115 [main] sshd 180 open_stackdumpfile: Dumping stack trace to > sshd.exe.stackdump > > 2 [main] sshd 2396 fork: child -1 - forked process 180 died > > unexpectedly, > retry 0, exit code 256, errno 11" > > This is probably the same problem as reported in the thread starting at > > http://cygwin.com/ml/cygwin/2012-06/msg00089.html > > There's no solution yet, sorry. Just wanting to report that I'm seeing a very similar error on Windows 8 consumer preview with Cygwin snapshot from June 4, 2012. Yes, I realize that it isn't the latest snapshot - I'll see if I can test on something newer - for now this is just another data point for you. 3 [main] bash 3308 fhandler_dev_zero::fixup_mmap_after_fork: requested 0x7F51 != 0x0 mem alloc base 0x7F51, state 0x1000, size 143360, Win32 error 487 1990 268 [main] bash 3308 C:\cygwin\bin\bash.exe: *** fatal error in forked process - recreate_mmaps_after_fork_failed 1991 644 [main] bash 3308 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 19924 [main] TestScript 3744 fork: child -1 - forked process 3308 died unexpectedly, retry 0, exit code 256, errno 11 This was reproduced three times, and each had an error very similar to this one. At the time of the crash, a bash script was running which was probably invoking either another subshell or perl. Note that all DLLs had been rebased to not conflict with each other or with ASLR-relocated system DLLs. This error seems to be very similar to the errors recently reported by Bertrand Latinville and Arnon Yaari: * Win32 error is the same (487). * The same functions crashed: fixup_mmap_after_fork, recreate_mmaps_after_fork_failed * In general, the error looks about the same. Given that the problem hasn't been fixed and it seems to be most likely to be the same problem as the others, I doubt that upgrading to a newer Windows 8 and Cygwin will help. -- 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: Trusted Software Vendor
Greetings, Corinna Vinschen! >> Out of curiosity would downloading setup.exe using wget also work >> around the problem? >> >>> >> >>>Most likely. I don't think wget cares about protecting Windows users >> >>>from their own stupidity. If you use wget, you should know what you're >> >>>doing. >> >>> >> >>>How about you just give it a try? >> >> >> >> Er, I don't have this problem. I wasn't the one reporting it. >> > Downloading setup.exe with wget has another problem. The downloaded >> > file is missing the +x bit, IIRC. >> >> It's irrelevant for setup.exe. > It's not. Try to start any executable on a NTFS filesystem. Remove > the executable bits from all entries in the ACL. Try again. Sure that will cause issues, but read quote from the start. If you download setup.exe using wget, it's unlikely you'll be unable to run it. You need to do some real tinkering first to prevent that. -- WBR, Andrey Repin (anrdae...@freemail.ru) 19.06.2012, <04:24> Sorry for my terrible english...
TERM=dummy
Today i've noticed, that in MSYS console TERM=dummy. Why ? Previously it was set to "cygwin", and it worked fine. I guess this was caused by some upgrade. -- Kind regards Pavel Fedin Expert engineer, Samsung Moscow research center -- 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: TERM=dummy
On 6/19/2012 7:21 AM, Fedin Pavel wrote: Today i've noticed, that in MSYS console TERM=dummy. Why ? Previously it was set to "cygwin", and it worked fine. I guess this was caused by some upgrade. than you should ask to MSYS mailing list Regards Marco -- 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: TERM=dummy
On 19.06.2012 10:46, marco atzeri wrote: than you should ask to MSYS mailing list Ooops, sorry... :) My head has seriously messed up... :) -- Kind regards Pavel Fedin Expert engineer, Samsung Moscow research center -- 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
