Mail Archives: djgpp/2019/06/20/07:33:54
On Thu, 20 Jun 2019 02:22:43 +0200
"J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]"
<djgpp AT delorie DOT com> wrote:
> On 2019-06-19 03:43, Rod Pemberton wrote:
> > b) how did you notice this issue originally?
> > c) is the "clobbering" actually causing corruption in your
> > program?
>
> It is causing very obvious corruption, that's how I discovered it.
> Variables changing for no reason. Then a pointer or some offset
> changes and the next access triggers a page or GP fault.
Does DJGPP's symify tell you anything about the page fault or GP fault?
Does a printf() placed nearby eliminate the issue? (memory allocation)
Are you accessing memory that hasn't been allocated? (buffer overflow)
Are you using any assembly? (register corruption)
> Running in a
> debugger throws things off just enough that it happens somewhere else
> on every run. I eventually tried hard-coding watchpoints and it
> triggered in a std::unordered_map node constructor. Backtracking
> through the disassembled code, I can only conclude that the offending
> pointer was returned directly from malloc. That's when I came up with
> this (flawed) method of detecting memory overlaps.
This reminds me of the issue of memory problems with DJGPP going away
when you use printf() to debug. printf() allocates additional memory.
> Just now I had another watchpoint hit in mv2freelist() (at
> src/libc/ansi/stdlib/nmalloc.c:524), which was called from malloc().
I'm not familiar with mv2freelist().
mv2freelist() doesn't seem to be in the DJGPP code or binaries at least
for DJGPP v2.03. (circa 2003)
Searching for mv2freelist() via Google finds:
http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/03/28/05:12:38
This post by Andris Pavenis refers to both an issue with malloc, and
something called nmalloc.
Is nmalloc() used in v2.04 or v2.05? ...
"/* Copyright (c) 2003 by Charles B. Falconer "
No comment.
It goes on:
" /* A re-implementation of malloc and friends for DJGPP 2.03/2.04
This includes many bits modeled after DJs original scheme.
This is NOT portable - it builds in knowledge of int size etc.
i.e. unsigned ints and pointers are both 32 bits (size 4)
The system is NOT thread and interrupt safe, although use of a
suitable critical section call could make it such. Nothing
herein executes for any unusual length of time (with NDEBUG).
*/"
> It's triggered on access to 'm->prevfree' which means the pointer 'm'
> overlaps with memory I previously allocated in a std::vector.
> So either I'm looking at a bug in malloc which only happens under
> _very_ specific circumstances, or more likely, something in my code
> is trashing malloc's internal data structures. I just fail to see
> what would cause that. In any case it's proving very hard to debug
> since the slightest changes to the code means some other memory area
> will be affected, and triggering watchpoints is based on sheer luck.
I know you think it's malloc (or perhaps nmalloc), but is it possible to
reduce your code - instead of creating a new test case - into a snippet
of failing code? Yes, that's unlikely for a large or complex program.
Are you using any other "advanced" features of DJGPP like DPMI to
allocate memory, nearptr's or farptr's, transfer buffer, etc?
> See the attachment to my reply to Eli Zaretskii,
After converting it to ANSI C "gcc -Wall -ansi -pedantic" (my
choice ...) and replacing rawclock() with time(NULL), it compiled
cleanly, and it repeatedly ran fine without reporting any pointer
matches.
Rod Pemberton
--
Once upon a time, many decades ago in a place far away, humble people
sought their freedom, and lost. "Ideas are bulletproof."
- Raw text -