Message-Id: <199803100817.KAA75416@ieva06.lanet.lv> From: "Andris Pavenis" To: Peter Palotas , Thomas Demmer 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 , > Thomas Demmer > From: Nate Eldredge > 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