Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Dave Korn" To: Subject: RE: signal trouble Date: Tue, 23 Aug 2005 13:35:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <4a03a72c050823024012eb6fe7@mail.gmail.com> Message-ID: ----Original Message---- >From: znort >Sent: 23 August 2005 10:40 > Could you tell/help me why the little code : > Under cygwin gcc version 3.4.4 (cygming special) and Linux with gcc 3.3.5 > same "strange" results... (no segmentation fault with cygwin anyway) Hm. Worked fine for me on RH8 with gcc 3.2. There in fact _is_ a segfault under cygwin, but it doesn't get printed out because either 1) everything blows up before stderr can be flushed or 2) everything blows up so badly it's no longer possible to print to stdout. > (notes : Under Solaris x86 (gcc3.4.4) it works perfectly !?) > > I think I've forgotten something but where ? > > help me please Not sure yet. It seems that the second time the SEGV happens, the signal handling code inside cygwin goes wrong somehow and ends up with a SEGV of its own and the app gets terminated without your handler being called. Unless there's some POSIX issue I don't know about to do with the way in which you re-enable signals or interactions between longjmp and signal handlers, I'd say it's a cygwin bug. cheers, DaveK -- Can't think of a witty .sigline today.... -- 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/