Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
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 <kcamera AT bwrc DOT eecs DOT berkeley DOT edu>
To: "'Mumit Khan '" <khan AT NanoTech DOT Wisc DOT EDU>,
        Kevin Camera
	 <kcamera AT bwrc DOT eecs DOT berkeley DOT edu>
Cc: "''cygwin AT cygwin DOT com' '" <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