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 Message-ID: <42C2B809.6C7821A1@dessent.net> Date: Wed, 29 Jun 2005 08:02:33 -0700 From: Brian Dessent MIME-Version: 1.0 To: Kris Thielemans CC: Gnuwin , "'Kris Thielemans'" Subject: Re: Gdb and stopping at assert or segmentation faults References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Report: -5.9/5.0 ---- Start SpamAssassin results * -3.3 ALL_TRUSTED Did not pass through any untrusted hosts * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * 0.0 AWL AWL: From: address is in the auto white-list ---- End SpamAssassin results X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Kris Thielemans wrote: > I need to debug a program that throws up an assert(). On Linux, I'm used to > be able to run the program in gdb, and when the assert happens, the program > stops (in the assert function) and I can do a back trace (e.g. info stack). > On cygwin on the other hand, I just get the assert message, and then gdb > says "Program exited normally". No backtrace possible. > > The same difference in behaviour between Linux and cygwin with segmentation > faults. It would be incredibly useful to be able to see where the > segmentation fault happened after the crash. You need to set the 'error_start' parameter of the CYGWIN environment variable to the (windows) path of gdb. You can also call cygwin_internal (CW_DEBUG_SELF, "c:\\path\\to\\gdb.exe") in your code to force a fault. Brian -- 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/