Board index » delphi » GPF caused by WMEM.ASM in BP7

GPF caused by WMEM.ASM in BP7

Hi,

I have written two programs using BP7 and OWL and I keep on getting those
dreaded GPF's when initialising edit and static controls for some of my
dialog boxes. When doing debugging with Turbo De{*word*81} I am able to trace
the source of the error to the Turbo Pascal Runtime Library Protected Mode
Memory Manager. The source code is on a file called WMEM.ASM which is on the
distribution disks.

The error always occurs on the line marked *** in the following routine:

; Allocate block from heap segment
; In    AX = Block size
;       ES = Heap segment
; Out   BX = Block offset
;       CF = 1 if error

NewBlock:

        MOV     BX,OFFSET hsFreeList
@@1:    MOV     SI,BX
        MOV     BX,ES:[BX].hbNext
        CMP     BX,1
        JB      @@3
        MOV     DX,ES:[BX].hbSize
        SUB     DX,AX
        JB      @@1
        MOV     CX,ES:[BX].hbNext
        JE      @@2
        MOV     DI,BX
        ADD     DI,AX
***     MOV     ES:[DI].hbNext,CX
        MOV     ES:[DI].hbSize,DX
        MOV     CX,DI
@@2:    MOV     ES:[SI].hbNext,CX
        SUB     ES:hsMemFree,AX
        CLC
@@3:    RET

The memory location pointed to by ES:[DI] seems to be invalid. My knowledge
of assembly language is fairly limited and I haven't been able to determine
the cause of the problem. Is it something to do with my heap and/or stack
sizes or is there something else that I'm doing wrong?

Any help would be much appreciated.

Thanks,

Frank.

=======================================
Frank Sokolic
Geographical and Environmental Sciences
University of Natal
Durban, South Africa
email: soko...@mtb.und.ac.za
=======================================

 

Re:GPF caused by WMEM.ASM in BP7


Quote
Frank Sokolic wrote:

> Hi,

> I have written two programs using BP7 and OWL and I keep on getting those
> dreaded GPF's when initialising edit and static controls for some of my
> dialog boxes. When doing debugging with Turbo De{*word*81} I am able to trace
> the source of the error to the Turbo Pascal Runtime Library Protected Mode
> Memory Manager. The source code is on a file called WMEM.ASM which is on the
> distribution disks.

[code fragment snipped]

Quote

> The memory location pointed to by ES:[DI] seems to be invalid. My knowledge
> of assembly language is fairly limited and I haven't been able to determine
> the cause of the problem. Is it something to do with my heap and/or stack
> sizes or is there something else that I'm doing wrong?

I sometimes got these as well, but I found they were _always_
caused by some error on my part, usually in the manipulation
of the strings involved: either defined them 1 character too
short, or forgot to initialise them correctly or something
like that. Also, a nice way to get into trouble is destroying
a string twice (preferably in different routines...).

From the code snippet you gave, it looks like the error surfaces
in the heap manager part that manages the list of freed blocks.
(note: surfaces there, but probably was caused earlier).

I would check _all_ (:[) code involving memory allocation/
deallocation involving the edit/static controls affected. Don't
forget the strCopy/Strdispose functions.

Good hunting,

Remco
--
_________________________________________________________________
Remco Vietor                            Department of Chemistry
re...@chem.gla.ac.uk                       J. Black Building
                                        University of Glasgow
                                        Glasgow G12 8QQ
                                        U.K.

Re:GPF caused by WMEM.ASM in BP7


In <344E03E9....@chem.gla.ac.xukx>,

Quote
Remco Vi?tor <re...@chem.gla.ac.xukx> wrote:
> I sometimes got these as well, but I found they were _always_
> caused by some error on my part, usually in the manipulation
> of the strings involved: either defined them 1 character too
> short, or forgot to initialise them correctly or something
> like that. Also, a nice way to get into trouble is destroying
> a string twice (preferably in different routines...).

Not sure if it helps, but I made a patch to heap.asm/wmem.asm to do a few
more checks. I did it after I had spent hours tracking down a memory
management bug in a program. The patch is archived at
http://www-edu.gel.usherb.ca/codc01/bp.html

If it helps, please let me know.

--
Frank Heckenbach, Erlangen, Germany
heckenb@[NOSPAM.REMOVE.THIS]mi.uni-erlangen.de
Internet links:        http://home.pages.de/~fjf/links.htm
Turbo Pascal programs: http://home.pages.de/~fjf/programs.htm

Other Threads