Mail Archives: djgpp-workers/2001/07/23/09:53:41
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 -