Mail Archives: djgpp/1998/05/21/10:16:30
In article <m0yc89j-000S40C AT inti DOT gov DOT ar>,
"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar> wrote:
>
> nobody AT REPLAY DOT COM (Anonymous) <---- I think I know this guy ;-) wrote:
You do!? Sometimes I wonder if I really know myself, so if you know, send me
a message and let me in on it too.
> > I think I am having a problem with memory leaks, so I am using memory
> > checkers to keep track of wild pointers.
> >
> > At first I attempted a port of a library called MEMDEBUG and linked it with
> > my code. It worked, but I didn't like it. Then I went to DMALLOC, which
> > was difficult to port because it wants to be a malloc replacement rather
> > than wrap around it. I noticed that the successfully linked code abruptly
> > exited from rhide (with a SIGABRT) and a display of the assembly debug
> > window; it never got into main().
> >
> > Then I went to something called DBMALLOC that shows promise, another library
> > set up for Unix but something that is not too hard to port. Damn it all
> > if it didn't do the same thing.
>
> There are TWO working packages for djgpp, why did you tried to port another?
> Here are the links from my links page:
>
NOW you tell me!<g> Okay, MSS and Fortify are on my hard disk now, uncompressed, the
files in the proper places.
----------
In article <Pine DOT SUN DOT 3 DOT 91 DOT 980520122930 DOT 24974S-100000 AT is>,
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
>
>
> On Tue, 19 May 1998, Anonymous wrote:
>
> > Load failed for image \obj/myprog.exe
>
> This shouldn't happen. You should try to understand why did GDB fail
> to load the program. It works for me.
>
> > 'symify' reveals nothing but the command itself in the output file
> > (assuming a clear screen).
>
> I don't understand. What's that ``clear screen'' business about? Did
> you try to run `symify' when no crash traceback is displayed on the
> screen? If so, it indeed won't work, since it doesn't have anything
> to symify.
>
> > Clearly there is something bad happening between the startup code
> > and the malloc (wrapper?) functions in the malloc debugging library.
> > I can't imagine how they could prevent a simple startup.
>
> The startup code is mostly C, and it itself calls malloc. If there's
> some bug or incompatibility with DJGPP in the replacement malloc, the
> startup will crash.
>
> Please post the symified crash traceback here. Please make sure you
> compile your program with -g, so that `symify' will have symbols to
> report. Also, please run your program from the command line, not from
> RHIDE, when you are generating the traceback.
You know, I had big response all set up to answer your comments, which was
to state I pretty much had done all what you suggest I do. But
it all became moot. You see, I took up SET's suggestion to get libraries
that claim to do what I probably want. I read the rather well-documented
library on Picazo & Palotas' MSS, set it up in RHIDE, then linked in with
my program, and I don't see this behavior now. Since P & P and the author
of Fortify set things up to work specifically with djgpp, there is no
effort now. I think the problem amounts to the difficulty of porting code
written to serve one system. Clearly I need to take apart the modules and
look at hundreds of lines of code and preprocessed code to figure out where
the headache is with those other libraries.
But you can answer a question on a totally different topic:
How does one declare a definition for a structure (as you find in MASM or TASM)
using GNU assembler? I have seen the "workarounds", and as far as I can tell,
those are just uniquely defined symbols pretending to be references to structure
members.
- Raw text -