X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Sat, 19 Dec 2009 13:03:22 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: 2nd occurrence of signal not being handled? Message-ID: <20091219180322.GB7183@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 On Sat, Dec 19, 2009 at 05:23:42AM +0000, Mark Geisert wrote: >I'm trying to get a larger application working but have an issue with >signal handling. I've boiled the issue down to the STC below. It >causes two access violations, only the first of which gets handled by >the SIGSEGV signal handler I've registered for the purpose. The second >access violation kills the program, as if the handler were no longer >registered. Using diagnostic code not shown I've made sure the handler >is still registered, but somehow it's not being called by Cygwin's >internal fault handling. Or maybe there's some subtle mistake in my >use of the signal functions. Any advice would be appreciated. I don't suppose you tried it on linux? Cygwin behaves the same way as linux. There may be some sa_flags setting that will cause the handler to continue to be arms. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple