delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/09/26/15:30:17

From: GAMMELJL AT SLU DOT EDU
Date: Sun, 26 Sep 1999 13:45:51 -0500 (CDT)
Subject: Re: problem with new malloc.c attn: Eli Zaretskii
To: djgpp AT delorie DOT com
Message-id: <01JGFEX6A3QM8WVZGM@SLU.EDU>
Organization: SAINT LOUIS UNIVERSITY St. Louis, MO
X-VMS-To: IN%"djgpp AT delorie DOT com"
MIME-version: 1.0
Reply-To: djgpp AT delorie DOT com

     When I #include malloc.c in my source file, I have no idea why
the symifier reports a _free statement at line 312 of my source code.
I note that the line numbers for main() all come after the line
numbers for malloc.c just as though malloc.c had been part of my
source code.  I thought it was just something the symifier does when
there are user written include files (the new malloc.c is essentially
a user written include file but not written by me).
     When I noticed that, I switched to what you see in my most recent
posting to djgpp.  That is, I copied malloc.c using the DOS editor
and pasted it into my source code after main (I omit #include malloc.c
when I do that).  That made it possible to show explicitly exactly what
I do to stop the scrolling of error screens (see the lines near 
if (qqq==4) in the copied malloc.c).  The line numbers for main() then
come before the line numbers for malloc.c in the symified dumpfile.
I posted that symified dumpfile as a comment in my most recent posting
to djgpp (it still refers to _free).
     You sent instructions about a scheme for pinning down the problem.
I will do my best to read the FAQ as you suggested as soon as you have
confirmed to me that that is your current position about what I should
do.  One of your messages confirmed that you believe there is an error
in the djgpp memory managers and something is getting overwritten.  I
would like to see that fixed and will do what I can to pinpoint the
problem.  

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019