delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/07/23/09:53:41

Date: Mon, 23 Jul 2001 16:54:24 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Andrew Cottrell <acottrel AT ihug DOT com DOT au>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Make 3.791 on Windows 2000 test
In-Reply-To: <002501c11375$33f5e960$0a02a8c0@acceleron>
Message-ID: <Pine.SUN.3.91.1010723163744.19800A-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Mon, 23 Jul 2001, Andrew Cottrell wrote:

> > > >         make.exe[1]: Entering directory `d:/dj204/gnu/make-3.791'
> > > >         Extended Error 183
> > Any luck in finding out where did this message come from?
> No I have looked in the bin exe files, c files, h files for the string
> "Extended Error", but so far no luck. I will take another track in trying to
> find where the message is output from. It is a stderr output. I will modifiy
> make source code to output file and line numbers whenever a stderr message
> is printed in the make src code.

I don't think this message comes from Make.  I think it comes from some 
program run by Make.  So looking at the lines that Make runs near the 
place where this message is printed might show the potential offenders.

> > > I have download YAMD to see if this can find anything tomorrow night.
> >
> > YAMD will not help you on Windows, because it relies on support for
> > function 0507h of Int 31h, which is part of DPMI 1.0 and unsupported by
> > Windows (this is the same function our startup code uses to uncommit the
> > null page and catch NUL pointer dereferences).
> 
> On the Win 98 box I re-started in DOS mode , not a DOS BOX and I got the
> same traceback for the leak info from YAMD in DOS as I did on NT.

Do I understand correctly that, when you used Make built with YAMD in DOS 
mode, you saw the same crash inside malloc as the crash you reported on 
Windows 2000?  If so, it's probably better to debug this in plain DOS 
mode.

But I don't see any clear sign of trouble in the YAMD report you posted 
(see below).  Reports about memory leaks is not what YAMD should show 
when it detects bugs of the kind that cause crashes inside malloc.

> WARNING: Memory leak
> Address 0x0d9ff2, size 14
> Allocated by malloc at
>  ???:0(_getpwnam+805)  0x02db99
>  ???:0(_getpwnam+923)  0x02dc0f
>  ???:0(___main+57)  0x030749
>  ???:0(___crt1_startup+164)  0x0222a8
>  ???:0(0x1293+0)  0x001293

This is not necessarily a bug.  If some chunk of memory is needed during 
the entire run, it is perfectly normal for a program to allocate it at 
the beginning and never to free it.  When the program exits, all its 
memory is deallocated anyway, so there's no leak involved.

I didn't analyze Make's source code to see if this is the case here, but 
it looks like that.

What you should look for is not reports about leaks, but _crashes_ due to 
Page Fault.  This is how YAMD catches invalid memory accesses: it causes 
the offending code to crash.  It does so by making the memory page 
immediately after the allocated region to be uncommitted from the 
program's address space (that's where it needs DPMI function 0507h).  So 
if any code writes beyond the allocated region, it will get a Page Fault 
and crash.  Running SYMIFY then should pinpoint the offending source line.

- Raw text -


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