Date:	Thu, 25 Aug 1994 12:32:06 -0400 (EDT)
From:	Edwin Phillips <flaregun AT strauss DOT udel DOT edu>
Subject:	Re: Catastrophic problems with v. 1.12
To:	DJGPP mailing list <djgpp AT sun DOT soe DOT clarkson DOT edu>

On Thu, 25 Aug 1994, HANS ELLENBERGER wrote:

> 
> 
> Having asked twice for confirmation of successful compilation of
> production programs (bigger than the tiny test.bat's) without any
> result, I come to the conclusion that djgpp v. 1.12 is not
> heavily used for production purposes.
> 
> This is somehow surprising, but reflects my own mixed experiences
> with it from version 1.11 on.
> 
> 
> Problem areas:
> 
>    -  Memory allocation is still buggy. Library calls of spawn
>       and stat often result in segment violation at malloc+200.
>    
>    -  Free physical memory reported is wrong when chunks bigger
>       than 4096 bytes are requested by malloc or sbrk.
>    
>    -  Debugging of real world applications using spawn is very
>       difficult because the topline of go32 is not updated when
>       the spawned program terminates.
>    
>    -  When spawning to another exe (e.g. as.exe), topline often
>       shows something like 2M of swapped out ram, 244K of used
>       ram and 16K of free ram in a system with 12M free xms ram
>       where swapping should not occur at all. It then spends most
>       of the time in real mode and execution is extremely slowed
>       down.
> 
>    - Calling system("mybat.bat arg1 arg2") hangs.
> 
> [...]
> 
> Segment violations without dpmi
> ===============================
> eax=000a3600 ebx=00000002 ecx=00000200 edx=0000001c esi=fffffffc edi=7ffff19b
> ebp=7ffff130 esp=7ffff124 cs=d8 ds=48 es=48 fs=48 gs=48 ss=48 cr2=00000200
> Call frame traceback EIPs:
>   0x0005459c _malloc+200
>   0x00054e6f _strdup+31
>   0x00054a3e _sprintf+190
>   0x00054bb5 _stat+297
>   0x......
> 
> eax=7fffe888 ebx=00000002 ecx=16006800 edx=0000001c esi=fffffffc edi=7fffe79e
> ebp=7fffe740 esp=7fffe734 cs=d8 ds=48 es=48 fs=48 gs=48 ss=48 cr2=00006800
> Call frame traceback EIPs:
>   0x0006bea4 _malloc+200
>   0x0006cb79 _spawnlpe+2201
>   0x0006cdab _spawnve+243
>   0x0006cf1b _spawnvpe+315
>   0x0006c2de _spawnlp+24
>   0x.......
> 
> Protection faults with dpmi form windows 3.1
> ============================================
> General Protection Fault at eip=5459c
> eax=000e3500 ebx=00000002 ecx=6d2e736c edx=0000001c esi=fffffffc edi=000e11cb
> ebp=000e1160 esp=000e1154 cs=cf ds=c7 es=c7 fs=c7 gs=c7 ss=d7 cr2=00001fe4
> Call frame traceback EIPs:
>   0x0005459c _malloc+200
>   0x00054e6f _strdup+31
>   0x00054a3e _sprintf+190
>   0x00054bb5 _stat+297
>   0x....
> ===========
> -----------
> 
>

  Hans,

  99% of all protection faults/segmentation violations which occur in
malloc are caused by the C program calling free(<garbage>).  The results
of doing this vary, but MAY eventually cause malloc() to fail.  You should
probably get a debugging version of malloc, free, etc.  Then you can be
sure that your code is not stomping on the heap.  :)

  Ed

/****************************************************************************/
/* Ed Phillips  flaregun AT strauss DOT udel DOT edu      University of Delaware       */
/* Jr Systems Programmer  (302) 831-6082    IT/Network and Systems Services */
/****************************************************************************/

- Raw text -