flat assembler
Message board for the users of flat assembler.

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

Author
Thread Post new topic Reply to topic
Trinitek



Joined: 06 Nov 2011
Posts: 257
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
Post 22 Oct 2015, 08:26
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 683
Location: Adelaide
Doesn't DOS set SS:SP to be PSP:FFFE? Then you are overwriting your stack with bufferB.
Post 22 Oct 2015, 08:35
View user's profile Send private message Reply with quote
Trinitek



Joined: 06 Nov 2011
Posts: 257
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.
Post 22 Oct 2015, 19:54
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 202
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.
Post 22 Oct 2015, 22:12
View user's profile Send private message Reply with quote
Trinitek



Joined: 06 Nov 2011
Posts: 257
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
Post 22 Oct 2015, 22:17
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 683
Location: Adelaide
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
Post 23 Oct 2015, 00:46
View user's profile Send private message Reply with quote
Trinitek



Joined: 06 Nov 2011
Posts: 257
Oh, I didn't even open the link. I was in a rush to get somewhere. Embarassed Thanks everybody.
Post 23 Oct 2015, 00:54
View user's profile Send private message Reply with quote
freecrac



Joined: 19 Oct 2011
Posts: 117
Location: Germany Hamburg
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
Post 25 Oct 2015, 06:31
View user's profile Send private message Send e-mail Reply with quote
Trinitek



Joined: 06 Nov 2011
Posts: 257
The buffers don't have to be consecutive; they're independent of each other. I hope I understand you correctly.
Post 25 Oct 2015, 08:36
View user's profile Send private message Reply with quote
freecrac



Joined: 19 Oct 2011
Posts: 117
Location: Germany Hamburg
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
Post 25 Oct 2015, 16:19
View user's profile Send private message Send e-mail Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.