DOS returns alloc'd memory that is already in use

Index > DOS > DOS returns alloc'd memory that is already in use

Author

Thread

Trinitek

Joined: 06 Nov 2011
Posts: 257

Trinitek 22 Oct 2015, 08:26

I'm not sure what to think of this. I'm allocating two offscreen video buffers for mode 0x13, both 320*200 bytes in size. Writes to BufferA work perfectly fine, but it appears that there is some data at the beginning of BufferB that is in use. Overwriting this data will either cause the program to be unstable, or it will crash DOSBox completely. I have made sure that no other segments or addresses overlap this area. I have done plenty of isolated testing with this, so I am nearly completely certain that ax=0x48, int 0x21 is fully responsible for returning this bad block.

This is the memory allocation code found in canvas.asm.

Code:

bufferA dw ?
bufferB dw ?

; word <si> setVideoBufferSeg(void)
; SI = ptr to error string, null if successful.
setVideoBufferSeg:
    push ax
    push bx
    push es
    
    if _target = target.dos
        mov ah, 0x4A                ; resize program's memory space to free unused memory
        mov bx, ds                  ; DOS allocates the largest block available for COM executables
        push es
        mov es, bx
        mov bx, endOfProgram/16     ; 16 bytes per paragraph
        int 0x21
        pop es
        
        macro errorHandle_malloc _bufferPtr* {
            local allOk
        
            jc @f                   ; no error?
            mov word [_bufferPtr], ax
            xor si, si              ; null si, save segment
            jmp .#allOk
            
            @@:
            cmp ax, 0x07            ; error code 0x07?
            jne @f
            mov si, err_mcb
            jmp .end
            
            @@:
            mov si, err_nomem       ; error code 0x08?
            jmp .end
            
            .#allOk:
        }
        
        mov ah, 0x48                ; allocate memory for bufferA
        mov bx, (320*200)/16        ; 16 bytes per paragraph
        int 0x21
        errorHandle_malloc bufferA  ; handle any errors
        
        mov ah, 0x48                ; allocate memory for bufferB
        mov bx, (320*200)/16        ; 16 bytes per paragraph
        int 0x21
        errorHandle_malloc bufferB  ; handle any errors
        
        postpone {
            err_mcb:
                    db "Can't allocate video buffer: memory control block destroyed", 0x0D, 0x0A, 0
            err_nomem:
                    db "Can't allocate video buffer: insufficient memory", 0x0D, 0x0A, 0
        }
        
    else if _target = target.mikeos
        mov ax, ds
        add ax, 0x1000
        mov word [bufferA], ax
        add ax, 0x1000
        mov word [bufferB], ax
    end if
    
    .end:
        pop es
        pop bx
        pop ax
        ret

This is the main project file, in which all other source files are included. Building this file will build the project.

Code:

; ...miscellaneous defines, macros

; ...includes
include 'canvas.asm'
; ...more includes

postpone {
    align 16
    endOfProgram:
}

Any ideas?

Last edited by Trinitek on 22 Oct 2015, 08:48; edited 1 time in total

22 Oct 2015, 08:26

sinsi

Joined: 10 Aug 2007
Posts: 794
Location: Adelaide

sinsi 22 Oct 2015, 08:35

Doesn't DOS set SS:SP to be PSP:FFFE? Then you are overwriting your stack with bufferB.

22 Oct 2015, 08:35

Trinitek

Joined: 06 Nov 2011
Posts: 257

Trinitek 22 Oct 2015, 19:54

I vaguely remember reading that a long time ago, now that you mention it, but I'm having a bit of trouble finding documentation that says that.

22 Oct 2015, 19:54

ACP

Joined: 23 Sep 2006
Posts: 204

ACP 22 Oct 2015, 22:12

SS:SP is set according to values in DOS MZ EXE header. Check out Ralf Brown Int List: http://www.ctyme.com/intr/rb-2939.htm

unless you are talking about COM files.

22 Oct 2015, 22:12

Trinitek

Joined: 06 Nov 2011
Posts: 257

Trinitek 22 Oct 2015, 22:17

Oh, sorry. It's a COM file. I should have clarified.

EDIT: Also, I have changed the routine to resize the program's block to a full 64k (0x1000 paragraphs) instead of endOfProgram/16. It appears to have fixed my issue, but I'd still like to see some documentation on the COM's stack location. Wink

22 Oct 2015, 22:17

sinsi

Joined: 10 Aug 2007
Posts: 794
Location: Adelaide

sinsi 23 Oct 2015, 00:46

From RBIL, DOS function 4B

Quote:

.COM-format executables begin running with the following register
values:
AL = 00h if first FCB has valid drive letter, FFh if not
AH = 00h if second FCB has valid drive letter, FFh if not
CS,DS,ES,SS = PSP segment
SP = offset of last word available in first 64K segment

23 Oct 2015, 00:46

Trinitek

Joined: 06 Nov 2011
Posts: 257

Trinitek 23 Oct 2015, 00:54

Oh, I didn't even open the link. I was in a rush to get somewhere. Embarassed

Thanks everybody.

23 Oct 2015, 00:54

freecrac

Joined: 19 Oct 2011
Posts: 117
Location: Germany Hamburg

freecrac 25 Oct 2015, 06:31

Hello.
I think one problem is to allocate two seperate memory locations and so we can not know if both buffers are seamless coherent or interrupted. Use only one (larger) allocation for both buffers example with 128 KB.

Dirk

25 Oct 2015, 06:31

Trinitek

Joined: 06 Nov 2011
Posts: 257

Trinitek 25 Oct 2015, 08:36

The buffers don't have to be consecutive; they're independent of each other. I hope I understand you correctly.

25 Oct 2015, 08:36

freecrac

Joined: 19 Oct 2011
Posts: 117
Location: Germany Hamburg

freecrac 25 Oct 2015, 16:19

Hello

Trinitek wrote:

The buffers don't have to be consecutive; they're independent of each other.

Ah, ok i see it now.

sinsi: Then you are overwriting your stack with bufferB

My modification (not tested yet):

Code:

        mov ah, 0x4A   ; resize program's memory space to free unused memory
        mov bx, ds     ; DOS allocates the largest block available for COM executables
        push es
        mov es, bx

     mov bx, sp
     add bx, 0Fh
     shr bx, 4
     add bx, endOfProgram/16     ; 16 bytes per paragraph
 
        int 0x21
        pop es

Dirk

25 Oct 2015, 16:19

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum