Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <011101c17c42$8db80e20$7add18ac@amr.corp.intel.com>
From: "Tim Prince" <tprince AT computer DOT org>
To: "Basant Kukreja" <Basant DOT Kukreja AT oracle DOT com>, <cygwin AT cygwin DOT com>
References: <3C0BDA7F DOT 9610AAC3 AT oracle DOT com>
Subject: Re: XP 64 bit : 32 bit emulation : fork problem : Cygwin 1.3.5
Date: Mon, 3 Dec 2001 13:36:19 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

The most recent success story I have heard, with a modified cygwin1.dll (not
supported on this list) was with XP Server build 3505.   My last success
with a Pro build was with build 2446.  These builds have changed continually
in the details relevant to cygwin, which must be one of the strategies
employed by Microsoft to discourage use of cygwin.
----- Original Message -----
From: "Basant Kukreja" <Basant DOT Kukreja AT oracle DOT com>
To: <cygwin AT cygwin DOT com>
Sent: Monday, December 03, 2001 12:03 PM
Subject: XP 64 bit : 32 bit emulation : fork problem : Cygwin 1.3.5


> Hi,
>     I tried to run Cygwin on Microsoft XP on 64 bit machine on itanium
> processor.
> I thought that 32 bit intel emulation should work. I installed on the
> itanium machine.
>
> I found that fork doesn't work. I downloaded the cygwin1 dll put few
> printfs to find
> out that fork is failing on alloc_stack_hard_way function during call of
> VirtualAlloc
> at the time of reserving stack. ( file name dcrt0.cc).
>
>   if (!VirtualAlloc (newbase, newlen, MEM_RESERVE, PAGE_NOACCESS))
>     api_fatal ("fork: can't reserve memory for stack %p - %p,  %p-%p \n
> base = %p allocbase = %p - regionsize= %p , %E",
>         ci->stacktop, ci->stackbottom, newbase, newlen, sm.BaseAddress,
> sm.AllocationBase, sm.RegionSize);
>
> The program failed by saying :
> fork : can't reserve memory for stack.
>
> I tried to find out difference between memory space while running on NT
> and while emulating on Win64. I could not figure it out the reasons. I
> can
> put the address space if you want.  I saw that the place it was trying
> to
> reserve was already reserved. When I commented this line and allow
> it to run futher it ran fine until
> user_data->main(...)
>
> I could not figure it out what this main points to so I could not debug
> futher.
>
> Regards,
> Basant.
>
> Cygwin 1.3.5 Dll was used.
>
> The test program is very simple.
>
> main()
> {
>         cout << "Parent Pid = " << getpid() << "\n";
>         int n = fork();
>         if( n == 0 )
>         {
>                 cout << "My Pid = "<< getpid() << "\n";
>                 // sleep (60);
>                 cout << "Child Proc\n";
>                 func();
>         }
>         else
>         {
>                 wait(0);
>                 cout<< "Parent Proc\n";
>         }
>         return 0;
> }
>
>
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/