Message-Id: <199803100817.KAA75416@ieva06.lanet.lv>
From: "Andris Pavenis" <pavenis AT laima DOT acad DOT latnet DOT lv>
To: Peter Palotas <blizzar AT hem1 DOT passagen DOT se>,
        Thomas Demmer <demmer AT LSTM DOT Ruhr-UNI-Bochum DOT De>
Date: Tue, 10 Mar 1998 10:14:53 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: MSS 10B
CC: djgpp AT delorie DOT com
In-reply-to: <199803100141.RAA17259@adit.ap.net>
Precedence: bulk

> Date:          Mon, 9 Mar 1998 17:41:15 -0800 (PST)
> To:            Peter Palotas <blizzar AT hem1 DOT passagen DOT se>,
>                Thomas Demmer <demmer AT LSTM DOT Ruhr-UNI-Bochum DOT De>
> From:          Nate Eldredge <eldredge AT ap DOT net>
> Subject:       Re: MSS 10B
> Cc:            djgpp AT delorie DOT com

> At 09:00  3/8/1998 -0500, Peter Palotas wrote:
> >At 19.59 1998-03-08 +0100, you wrote:
> >
> >Hi Tom,
> >
> >>Peter, 
> >>bad news, your program does not work together with
> >>TurboVision. Programs using TV fail to compile,
> >>I get a syntax error where TV overloads the new[]
> >>operator
> >
> >I guess I forgot to mention this problem in the documentation.
> >For the new[] operator overload I have no concrete solution yet, because
> >MSS needs to overload the new operator itself, and there will be a
> >conflict. I will try to find a solution as soon as possible though. I don't
> >think there will ever be a really GOOD solution for this though.
> 
> This is not a *good* solution, but it might help. G++ routes `new' calls to
> `malloc'. With a little linker magic, I believe you can get all `malloc'
> calls rerouted to your own routine. See the `--wrap' option to `ld'.
> 
> This doesn't allow you to get the line numbers, though. I suppose if you
> were *really* masochistic, you could make the user compile with `-g', then
> look at the stack for the address of their function and use the debug info
> to translate that into file and line number. `libdbg.a' has some routines
> that might help with that.
> 

I met the same problem with Fortify (I used version 1.0). Finally I used
very similar approach:
  
I modified libmmalloc.a that comes with sources of GDB (full version,
dropped in DJGPP) and joined this library together with code from fortify.
This approack allowed me to debug RHIDE that is not very easy target
for that (2 levels of memory allocation: malloc which calls mmalloc, 
libgdb.a uses the latest one).

 Initially I enabled checking all memory on all memory allocations and 
releases and checking correctness of all pointers to be released. 
This slows things a lot, therefore these extra tests were disabled 
later. Setting breakpoint in gdb to procedure that outputs message about 
error helped me to find some problems. Another way I used was to add 
procedure that checks all memory and displays error messages on memory 
corruption. Then I used print command from GDB to check where memory 
corruption occurs.

I think any such output will be much less detailed as the information I 
can get from gdb.

Of course overriding operator new causes problems with software that
also does the same (TVision is one example). The solution is simply
not to include .h file that defines it. This does not cause any problems 
with Fortify.  I didn't check it carefully with MSS (November version of
MSS causedf crashes under Linux, let's hope that's fixed in 1.0b, Fortify 
worked Ok in both DOS and Linux)

Andris