Re: Memory Management on AMD64 in 32-bit mode
Benson Margulies wrote: 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 easier to get a clue. I believe that there is some documentation in a file in the CVS for Cygwin. -- Joe Buehler -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Memory Management on AMD64 in 32-bit mode
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 easier to get a clue. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Memory Management on AMD64 in 32-bit mode
On Dec 9 12:55, Benson Margulies wrote:
I assume that there's a very strong reason why this code can't just
allocate a stack any-old-place (calling VirtualAlloc with first arg 0)
and use it. What I don't understand is the nature of the constraints. If
the parent needs to know, why not have stack_base make a call to
VirtualAlloc with first arg 0 to allocate a brand-new region, on the
theory that such a region is a lot more likely to end up with a
corresponding hole in the child process?
Just an example:
void foo()
{
int x = 1;
int *xp = x;
if (!fork())/* Child */
printf (%d\n, *xp);
}
What happens if the stack of the child has been allocated at another
address as the parent's stack?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Memory Management on AMD64 in 32-bit mode
What is more : sometimes I get the same type of messages on an Intel Xeon based system. I think that I have a chance of 1 in 500 before I get the same problem, and this is with a program which forks several subprocesses and enters a loop with ticks of 1 s for waiting on finished processes and launching another one. I think it is more an error in the operating system, which may get worse by running on AMD. Regards, Jurgen Christopher Faylor [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/09/2003 02:18 AM Please respond to cygwin To: [EMAIL PROTECTED] cc: (bcc: Jurgen Defurne/BRG/CE/PHILIPS) Subject:Re: Memory Management on AMD64 in 32-bit mode Classification: On Mon, Dec 08, 2003 at 07:30:17PM -0500, Benson Margulies wrote: 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. Sorry but this is not a now try this type of debugging activity. It would require quite a bit of effort to track this problem down. As I've said before, it would require physical access to a 64 bit system. -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Memory Management on AMD64 in 32-bit mode
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 a call to VA against already reserved storage. It is also not altogether displeased. Can someone explain the design of the path of code in stack allocation that calls VQ and then runs around and calls VA? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Memory Management on AMD64 in 32-bit mode
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 stack_base is called. alloc_stack_hard_way is called when the region containing the stack as of the call to alloc_stack is at the same place as the region containing the stack at the time that stack_base was called. I don't exactly see how it is safe to assume that the child process will have unused memory at the location that corresponds to the parent process's stack region at the time that stack_base was called, but I've only spent 1 hour on the problem. In any case, it isn't available. A minor problem: %E always says Win32 error 0 even when GetLastError() returns a non-zero value. In fact, VirtualAlloc is setting the last error to what one would expect. I assume that there's a very strong reason why this code can't just allocate a stack any-old-place (calling VirtualAlloc with first arg 0) and use it. What I don't understand is the nature of the constraints. If the parent needs to know, why not have stack_base make a call to VirtualAlloc with first arg 0 to allocate a brand-new region, on the theory that such a region is a lot more likely to end up with a corresponding hole in the child process? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Memory Management on AMD64 in 32-bit mode
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 0x41 - 0x610 000, Win32 error 0 35 [main] zsh 248 sync_with_child: child 2648(0x2C0) died before initializa tion with status code 0x1 214 [main] zsh 248 sync_with_child: *** child state waiting for longjmp zsh: fork failed: resource temporarily unavailable $P$G -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Memory Management on AMD64 in 32-bit mode
On Mon, Dec 08, 2003 at 07:30:17PM -0500, Benson Margulies wrote: 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. Sorry but this is not a now try this type of debugging activity. It would require quite a bit of effort to track this problem down. As I've said before, it would require physical access to a 64 bit system. -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
