Yea, that would help a great deal.
-Original Message-
From: Nathan Laredo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 3:08 PM
To: [EMAIL PROTECTED]; Benson Margulies; [EMAIL PROTECTED]
Subject: Re: Windows Server 2003 on AMD64 -- Making it work
Hi,
If you simply want to get
offenders are Java programs, but I can't find any
evidence that the Sun JVM calls SetErrorMode.
-Original Message-
From: Larry Hall [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 21, 2004 9:56 PM
To: Benson Margulies; [EMAIL PROTECTED]
Subject: Re: SetErrorMode
At 12:52 PM 3/21/2004, you
I'm trying to run some builds under cygwin with SetErrorMode set to
avoid Windows dialog boxes in the event of hard errors. I'm failing. I
get dialog boxes. Is cygwin doing anything to call SetErrorMode and undo
my efforts, or do I need to look elsewhere?
--
Unsubscribe info:
However we set up the text mode with mount, files referenced with drive
letters are being read with DOS line termination. Is there a way to
control this?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation:
We have pathnames that end up, sometimes, being passed to non-cygwin
.exe, and other times that are used with cygwin programs. We've been
using cygpath -m for this with a lot of success, but now we have to be
more careful, evidently.
--
Unsubscribe info:
I see that I missed a message. Corinna's message indicates that the
intention is that the stack location of the child be identical to the
parent, for pretty self-evident fork-semantics-reasons. I'll take
another dip into the code and see if I can figure something out.
--
Unsubscribe info:
I've belatedly located Corinna Vinschen's email message about the
requirement for the stack address in fork.
Would anyone be willing to elaborate on how the existing code is going
about accomplishing the task at hand? If not, at least knowing that this
is the goal of the exercise should make it
The error message rather unambiguously indicates that VirtualAlloc is
returning 0 with GetLastError() == 0. The call in question calls
VirtualAlloc with parameters derived from a call to VirtualQuery against
some stack storage. It seems that this version of Windows is not
altogether pleased to see
I've got the 1.5.5-1 sources, and everything else up-to-date.
c++ -L/cygdrive/c/benson/cygwindev/i686-pc-cygwin/winsup
-L/cygdrive/c/benson/cygwindev/i686-pc-cygwin/winsup/cygwin
-L/cygdrive/c/benson/cygwindev/i686-pc-cygwin/winsup/w32api/lib -isystem
/usr/src/cygwin-1.5.5-1/winsup/include
I diffed a machine where I can build with a machine where I can't. I'm
theorizing that the diff would be more informative, though nothing leaps
out at me. The 'from' of the diff is the machine where I can compile.
The 'to' is the machine where I can't.
3c3
Current System Time: Tue Dec 09
This looks like a logic error in fork.cc/dcrt0.cc to me, but I'm
probably not understanding something.
alloc_stack_hard_way assumes that the memory at ci-stacktop is
available. ci-stacktop is set to be the region of memory that contains
a stack variable in the parent process at the time that
I happen to have access to a an AMD64 system running Windows. All the
cygwin shells fail to fork with the following. I'd be willing to try
coding and running a patch if the experts would care to offer an idea of
what to try.
$P$Gls
C:\cygwin\bin\zsh.exe: *** fork: can't reserve memory for stack
most attempts to start xterms on my W2K SP2 with current security patches
fail with the following Starting from a non-X cygwin window succeeds
0 [main] xterm 1456 sync_with_child: child 1492(0x388) died before
initial
ization with status code 0x18B00
163 [main] xterm 1456
13 matches
Mail list logo
