Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <711F6B80B5B4D211BA900090272AB7649C4210@noyce.eecs.berkeley.edu> From: Kevin Camera To: "'Mumit Khan '" , Kevin Camera Cc: "''cygwin AT cygwin DOT com' '" Subject: RE: GCC untrackable crashes Date: Wed, 21 Feb 2001 17:23:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Mumit and others, Well, it was true that my character arrays were short by one character in the first case, and in the second case calling ofstream.clear() before reusing the stream got rid of all the seg faults. The program is fine now. With hindsight, I was completely confused and thrown off by the strange behavior I saw in GDB (meaning the lack of a stack trace or any other information about the seg fault). Luckily (for a hardware guy who known little about real programming) I managed to hand-step through the code and find the problematic lines... Would any of the GCC developers like my complete source example to add some functionality to the compiler or debugger to better catch/aviod these errors? Thanks! Kevin kcamera AT eecs DOT berkeley DOT edu -----Original Message----- From: Mumit Khan To: Kevin Camera Cc: 'cygwin AT cygwin DOT com' Sent: 2/21/01 4:26 PM Subject: RE: GCC untrackable crashes On Wed, 21 Feb 2001, Kevin Camera wrote: > I was recommended to add more details about this problem (the seg fault > within __size_of_stack_reserve). I was hesitant to do this because the code > seems to be pretty standard and works on all other machines. Kevin, You may be running into Cygwin or gcc bugs, and then again you may be running into bugs in your code. There is *no* way to tell without a working testcase, which means a complete program that we can run and test. Is there any way you can put these two in a complete program? There is one other issue I can see right away. > if ( currentState->entry != NULL ) { > // Allocate a new string buffer > length += strlen(currentState->entry); > tmpbuf = new char[length]; ^^^^^^^^ [length + 1] > // Copy in the new code and add the old at the end > strcpy(tmpbuf,currentState->entry); > strcat(tmpbuf,entrybuf); ^^^^^^^^^^^^^^^^^^^^^^^^ But you don't have enough room for this! Here's what I suggest -- use a memory debugger say on Linux or Solaris (ElectricFence works very well on both), and see what you find first. All those character strings could be very easily be replaced with std::string and memory trampling/leak issues go away. FYI, there is an obvious bug in your ofstream code that will trip you up, especially using some of the newer compilers with (almost) standard C++ library -- since you're reusing the same stream, you need to do a outfile.clear() before each open. It's not relevant here, since that particular problem will be caught by your code. Regards, Mumit -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple