Re: [PATCH] Prevent restart of crashing non-Cygwin exe

On Jun 24, Corinna Vinschen wrote:
> Hi Christian,
>
> On Jun 23 19:52, Christian Franke wrote:
>> If a non-Cygwin .exe started from a Cygwin shell window segfaults,
>> Cygwin restarts the .exe 5 times.
>> [...l]
>> 	* sigproc.cc (child_info::sync): Add exit_code to debug
>> 	message.
>> 	(child_info::proc_retry): Don't retry on unknown exit_code
>> 	from non-cygwin programs.
> This looks ok to me, but cgf should have a say here.  He's on vacation
> for another week, though.
>

Problem can still be reproduced with current CVS. Patch is still valid.

Christian

Re: [PATCH] Prevent restart of crashing non-Cygwin exe

On Nov  2 20:53, Christian Franke wrote:
> On Jun 24, Corinna Vinschen wrote:
> >Hi Christian,
> >
> >On Jun 23 19:52, Christian Franke wrote:
> >>If a non-Cygwin .exe started from a Cygwin shell window segfaults,
> >>Cygwin restarts the .exe 5 times.
> >>[...l]
> >>	* sigproc.cc (child_info::sync): Add exit_code to debug
> >>	message.
> >>	(child_info::proc_retry): Don't retry on unknown exit_code
> >>	from non-cygwin programs.
> >This looks ok to me, but cgf should have a say here.  He's on vacation
> >for another week, though.
> >
> 
> Problem can still be reproduced with current CVS. Patch is still valid.

Sorry, I forgot about this patch entirely.  Chris, is that patch ok with
you as well?

Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: Extend faq.using to discuss fork failures

On 30/08/2011 14:41, Ryan Johnson wrote:
> That sounds reasonable, though I suspect we'd want want to keep the concluding
> bits in the FAQ as well. Unfortunately, summertime free time has come to an
> end so I don't know when I'll get to this next. Perhaps a good compromise for
> now would be for you to post only the first FAQ question? That would at least
> cut traffic to the cygwin ML a bit.

I've updated Ryan's patch to hopefully address the comments made, polished the 
language a bit in places, and split it into a patch for the FAQ which just 
says how to fix problems and a patch for the UG which contains the technical 
details.

Index: doc/faq-using.xml
===================================================================
RCS file: /cvs/src/src/winsup/doc/faq-using.xml,v
retrieving revision 1.35
diff -u -p -r1.35 faq-using.xml
--- doc/faq-using.xml	4 Aug 2011 18:25:41 -0000	1.35
+++ doc/faq-using.xml	3 Nov 2011 16:26:56 -0000
 <at>  <at>  -1099,7 +1099,7  <at>  <at>  it.</para>
 IPv6 stack, see the <ulink
url="http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx">Microsoft TechNet IPv6 FAQ article</ulink>
 </para></answer></qandaentry>

-<qandaentry id="faq.using.bloda">
+<qandaentry id="faq.using.bloda" xreflabel="BLODA">
 <question><para>What applications have been found to interfere with Cygwin?</para></question>
 <answer>

Re: Extend faq.using to discuss fork failures

Hi Jon,

On Nov  3 16:35, Jon TURNEY wrote:
> On 30/08/2011 14:41, Ryan Johnson wrote:
> >That sounds reasonable, though I suspect we'd want want to keep the concluding
> >bits in the FAQ as well. Unfortunately, summertime free time has come to an
> >end so I don't know when I'll get to this next. Perhaps a good compromise for
> >now would be for you to post only the first FAQ question? That would at least
> >cut traffic to the cygwin ML a bit.
> 
> I've updated Ryan's patch to hopefully address the comments made,
> polished the language a bit in places, and split it into a patch for
> the FAQ which just says how to fix problems and a patch for the UG
> which contains the technical details.

Thanks for doing that.  I looks good to me, with just one exception.

> +<listitem>Address space layout randomization (ASLR). Starting with
> +Vista, Windows implements ASLR, which means that thread stacks,
> +heap, memory-mapped files, and statically-linked dlls are placed
> +at different (random) locations in each process. This behaviour
> +interferes with a proper <literal>fork</literal>, and if an
> +unmovable object (process heap or system dll) ends up at the wrong
> +location, Cygwin can do nothing to compensate (though it will
> +retry a few times automatically). In a 64-bit system, marking
> +executables as large address-ware and rebasing dlls to high
> +addresses has been reported to help, as ASLR affects only the
> +lower 2GB of address space.</listitem>

Starting with "In a 64-bit system" it's getting a bit weird:

Re: Extend faq.using to discuss fork failures

On Thu, Nov 03, 2011 at 04:35:25PM +0000, Jon TURNEY wrote:
>On 30/08/2011 14:41, Ryan Johnson wrote:
>> That sounds reasonable, though I suspect we'd want want to keep the concluding
>> bits in the FAQ as well. Unfortunately, summertime free time has come to an
>> end so I don't know when I'll get to this next. Perhaps a good compromise for
>> now would be for you to post only the first FAQ question? That would at least
>> cut traffic to the cygwin ML a bit.
>
>I've updated Ryan's patch to hopefully address the comments made, polished the 
>language a bit in places, and split it into a patch for the FAQ which just 
>says how to fix problems and a patch for the UG which contains the technical 
>details.

>Index: doc/faq-using.xml
>===================================================================
>RCS file: /cvs/src/src/winsup/doc/faq-using.xml,v
>retrieving revision 1.35
>diff -u -p -r1.35 faq-using.xml
>--- doc/faq-using.xml	4 Aug 2011 18:25:41 -0000	1.35
>+++ doc/faq-using.xml	3 Nov 2011 16:26:56 -0000
> <at>  <at>  -1099,7 +1099,7  <at>  <at>  it.</para>
> IPv6 stack, see the <ulink
url="http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx">Microsoft TechNet IPv6 FAQ article</ulink>
> </para></answer></qandaentry>
> 
>-<qandaentry id="faq.using.bloda">
>+<qandaentry id="faq.using.bloda" xreflabel="BLODA">
> <question><para>What applications have been found to interfere with Cygwin?</para></question>
> <answer>
> 

Re: [PATCH] Prevent restart of crashing non-Cygwin exe

On Thu, Nov 03, 2011 at 01:07:20PM +0100, Corinna Vinschen wrote:
>On Nov  2 20:53, Christian Franke wrote:
>> On Jun 24, Corinna Vinschen wrote:
>> >Hi Christian,
>> >
>> >On Jun 23 19:52, Christian Franke wrote:
>> >>If a non-Cygwin .exe started from a Cygwin shell window segfaults,
>> >>Cygwin restarts the .exe 5 times.
>> >>[...l]
>> >>	* sigproc.cc (child_info::sync): Add exit_code to debug
>> >>	message.
>> >>	(child_info::proc_retry): Don't retry on unknown exit_code
>> >>	from non-cygwin programs.
>> >This looks ok to me, but cgf should have a say here.  He's on vacation
>> >for another week, though.
>> >
>> 
>>Problem can still be reproduced with current CVS.  Patch is still
>>valid.
>
>Sorry, I forgot about this patch entirely.  Chris, is that patch ok
>with you as well?

No, it isn't.  Sorry for not stating this earlier.  The problem that
this code was intended to solve was actually a transient exit codes from
a non-Cygwin process which began with 0xc...

I don't believe that I ever saw STATUS_ACCESS_VIOLATION in any of my
testing though so adding that earlier in the switch would fix this
particular problem.  I'll do that.

Re: Extend faq.using to discuss fork failures

On 03/11/2011 21:05, Christopher Faylor wrote:
> I would still prefer eschewing actively negative words like "hostile" and just
> neutrally stating that Windows does not use a fork/exec model and does not offer
> any easy way to implement fork.

Hmm, yes, I'll fix that.

> I'd also like to see specific errors mentioned so that when people are searching for
> a solution to the problem they will be able to find it in the FAQ.

Is there something wrong with the itemized list which follows that sentence?

Re: Extend faq.using to discuss fork failures

On 03/11/2011 17:17, Corinna Vinschen wrote:
> Thanks for doing that.  I looks good to me, with just one exception.
>
>> +<listitem>Address space layout randomization (ASLR). Starting with
>> +Vista, Windows implements ASLR, which means that thread stacks,
>> +heap, memory-mapped files, and statically-linked dlls are placed
>> +at different (random) locations in each process. This behaviour
>> +interferes with a proper<literal>fork</literal>, and if an
>> +unmovable object (process heap or system dll) ends up at the wrong
>> +location, Cygwin can do nothing to compensate (though it will
>> +retry a few times automatically). In a 64-bit system, marking
>> +executables as large address-ware and rebasing dlls to high
>> +addresses has been reported to help, as ASLR affects only the
>> +lower 2GB of address space.</listitem>
>
> Starting with "In a 64-bit system" it's getting a bit weird:
>
> - Starting with 4.5.3, gcc marks executables as large address aware
>    automatically, so this is going to be a lesser problem over time.  Is
>    it worth to mention this at all?  I suppose so, but the user should be
>    pointed to peflags to tests for this property first for the given
>    reason.
>
> - Starting with Cygwin 1.7.10, the high address area will be used for
>    the application heap on 64 bit systems and large address aware
>    executables.  Mmaps are located there, too.  This in turn leaves more
>    room for DLLs in the normal 2 Gigs memory area.  Therefore I would not
>    like to suggest rebasing DLLs into the high address area at all.  This
>    should only be done by people who know what they are doing.  Usually
>    there should be enough space in the lower 2 Gigs, especially when heap

Re: Extend faq.using to discuss fork failures

On Fri, Nov 04, 2011 at 01:34:09PM +0000, Jon TURNEY wrote:
>On 03/11/2011 21:05, Christopher Faylor wrote:
>> I would still prefer eschewing actively negative words like "hostile" and just
>> neutrally stating that Windows does not use a fork/exec model and does not offer
>> any easy way to implement fork.
>
>Hmm, yes, I'll fix that.

Thanks.

>> I'd also like to see specific errors mentioned so that when people are searching for
>> a solution to the problem they will be able to find it in the FAQ.
>
>Is there something wrong with the itemized list which follows that sentence?

No, sorry.  I'm email challenged at the moment so I missed it.

cgf

Re: Extend faq.using to discuss fork failures

On Fri, Nov 04, 2011 at 12:22:13PM -0400, Christopher Faylor wrote:
>On Fri, Nov 04, 2011 at 01:34:09PM +0000, Jon TURNEY wrote:
>>On 03/11/2011 21:05, Christopher Faylor wrote:
>>> I would still prefer eschewing actively negative words like "hostile" and just
>>> neutrally stating that Windows does not use a fork/exec model and does not offer
>>> any easy way to implement fork.
>>
>>Hmm, yes, I'll fix that.
>
>Thanks.
>
>>> I'd also like to see specific errors mentioned so that when people are searching for
>>> a solution to the problem they will be able to find it in the FAQ.
>>
>>Is there something wrong with the itemized list which follows that sentence?
>
>No, sorry.  I'm email challenged at the moment so I missed it.

Btw, since this is such a glaring omission from the FAQ I think you
should make the edits that Corinna and I suggested and just check it
in.  We can tweak it as needed when people express confusion.

Thanks to you and Ryan for doing this.  We really needed it.

cgf