Mail Archives: djgpp/1994/08/25/15:52:03
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 -