Message-ID: <3F16D946.3060302@psy.kuleuven.ac.be>
Date: Thu, 17 Jul 2003 19:13:42 +0200
From: Peter Claessens <peter DOT claessens AT psy DOT kuleuven DOT ac DOT be>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: nl-BE,en
MIME-Version: 1.0
To: djgpp <djgpp AT delorie DOT com>
Subject: Re: malloc/free blues - for Peter Claessens
References: <3F156434 DOT 3000508 AT psy DOT kuleuven DOT ac DOT be> <3F16A652 DOT 24B6FEA5 AT psy DOT kuleuven DOT ac DOT be> <08da01c34c6b$be890bd0$0600000a AT broadpark DOT no> <7458-Thu17Jul2003175053+0300-eliz AT elta DOT co DOT il> <3f16bdbc DOT sandmann AT clio DOT rice DOT edu>
In-Reply-To: <3f16bdbc.sandmann@clio.rice.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by KULeuven Antivirus Cluster

Since you don't really use the source code I compiled the original code 
again, i.e. with the full drawing code instead of just the assignment 
and memory-related statements. It doesn't make any difference for the 
kind of commands that make the program crash: still memory-related 
crashes only.
Should I put this flags statement inside or outside the main() function, 
or doesn't it matter?
I put it before the main function for now and still have crashes at 
different points in the program, but the eip values reported seem to 
converge to 2 values. Some typical tracebacks and their associated x/i 
values.

General Protection Fault at eip=000c11f7
eax=6d657270 ebx=002396d0 ecx=002399b8 edx=6d657274 esi=002399b8 
edi=00000012
ebp=001e66f8 esp=001e66ec program=C:\SRC\DOTS2002\DOTREAD.EXE
cs: sel=00a7  base=10000000  limit=0058ffff
ds: sel=00af  base=10000000  limit=0058ffff
es: sel=00af  base=10000000  limit=0058ffff
fs: sel=00bf  base=00000000  limit=0010ffff
gs: sel=00bf  base=00000000  limit=0010ffff
ss: sel=00af  base=10000000  limit=0058ffff
App stack: [001e77c4..001677c4]  Exceptn stack: [00167708..001657c8]
 
Call frame traceback EIPs:
  0x000c11f7 free+271, file malloc.c
  0x000d4231 operator delete(void*)+21, file fnmatch.c
  0x000fda88 std::string::_Rep::_M_destroy..+40, file fnmatch.c
  0x000fb87b std::string::~string()+59, file fnmatch.c
  0x0004c090 readvar(std::string, std::st..+778, file c:/src/d..ig.cpp, 
line 162
 
x/i 0xc11f7 <free+271>: mov 0x4(%eax),%eax
 
Next is a page fault here but it often gets reported as general 
protection fault!
Page Fault at eip=000c1190, error=0006
eax=00234d68 ebx=0035e04c ecx=0035e04c edx=00161698 esi=0047812c 
edi=00000013
ebp=001e6678 esp=001e666c program=C:\SRC\DOTS2002\DOTREAD.EXE
cs: sel=00af  base=83d96000  limit=ffb54fff
ds: sel=00b7  base=83d96000  limit=ffb54fff
es: sel=00b7  base=83d96000  limit=ffb54fff
fs: sel=00c7  base=00000000  limit=0010ffff
gs: sel=00c7  base=00000000  limit=0010ffff
ss: sel=00b7  base=83d96000  limit=ffb54fff
App stack: [001e77c4..001677c4]  Exceptn stack: [00167708..001657c8]
 
Call frame traceback EIPs:
  0x000c1190 free+168, file malloc.c
  0x0006d30e destroy_bitmap+370, file c:/djgpp/allegro/src/graphics.c, 
line 1165
  0x000133d5 .debug_str+550, file c:/src/dots2002/grafx.cpp, line 2496

x/i: 0xc1190 <free+168>:     mov    %eax,0x4(%eax,%ecx,1)

Maybe it is interesting for you to know that sometimes the program 
doesn't crash. Sometimes it freezes, and triggers a GPF only after I 
press ctrl-c.


Charles Sandmann wrote:

>>>From: "Gisle Vanem" <giva AT bgnett DOT no>
>>>Date: Thu, 17 Jul 2003 16:00:13 +0200
>>>
>>>#include <crt0.h>
>>>int _crt0_startup_flags =  _CRT0_FLAG_FILL_SBRK_MEMORY |
>>>                  _CRT0_FLAG_FILL_DEADBEEF;
>>>
>>>in the main module.
>>>      
>>>
>>I think this will only help if an uninitialized pointers are passed to
>>`free'.  It is much more probable that the bug is in some code that
>>writes past the end of an allocated buffer; in that case, I don't
>>think the above will help (but it won't hurt to try that).
>>    
>>
>
>I agree he should set the deadbeef flag even if the problem is in free,
>since this will make the behavior consistent between runs.  For example,
>he might be passing an uninitialized value to free - and when you
>see the deadbeef (or something close) - you know you've got a bug.
>
>If the program fails in two different places when run twice, always
>fill the memory.
>  
>