Why the stack is corrupted in WinXP?

[sulaiman]

I'll rebuild the problem so that we can share the weird.

first of all,

1. open command prompt.
2. type "debug" without quote.

Code: Select all

-a100
0AF3:0100 mov ax,3 // enter twice here.
0AF3:0103 
-rip
IP 0100
:100  // if not 100, type 100 here.
-r
AX=0000  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=0AF3  ES=0AF3  SS=0AF3  CS=0AF3  IP=0100   NV UP EI PL NZ NA PO NC
0AF3:0100 B80300        MOV     AX,0003
// since our stack pointer located in ffee
// we will fill it with 0
-f ffe0 ffef 0
-d ffe0 ffef // to see that area, you will see zero
-t // type t (trace) and enter
-d ffe0 ffef // check the stack area again.
0AF3:FFE0  00 00 00 00 03 00 00 00-03 01 F3 0A 57 05 00 00   ............W...

can anyone tell me, where and why those weird values appear in stack area?

best regards,
Sulaiman Chang

[Therx]

why program with raw opcodes? Are yuo made ???

Good Luck ;D

Pete

[sulaiman]

it looks like people here is armed with armies...

oh God.... please forgive their ignorence

[sonneveld]

Well, I'm not sure what you're trying to do with the instructions but anything could be writing to the stack. It could be debug when you break out of the code or it could be a software interrupt called by a timer.

I know with the AGI interpreter, you had more chance of "out of stack error" with Windows than in DOS and that was probably because stray Windows software interrupts were being called and overwriting the end of the stack.

I don't think you're meant to look at anything you haven't pushed on the stack yourself.. it's old data.

I'll shush before it makes it even more obvious I don't know what I'm talking about

- Nick

[sulaiman]

the problem is, once you clear the stack area, and trace one instruction, you will see your stack area filled with ... weird value.

Code: Select all

-f ffe0 ffef 0
-t

stray Windows software

Ok, i see the reason.

[sonneveld]

That's the problem I think. You're tracing one instruction in the code you wrote but not all the code in the entire terminal window it's running in.

- Nick

[Schol-R-LEA]

I don't think that is right. DEBUG is a real mode program, and was never designed for a protected mode multitasking environment; both DEBUG itself and the program (if any) it is examining are isolated within a single v86 task, which creates the illusion of a single-tasking, real mode DOS environment. When you run DEBUG from the command prompt, it is essentially running in DOS emulation mode, which means that all of the Windows activity should be hidden from it and inaccessible to it - it should act as if it were running under DOS.

Of course, that's 'should', not necessarily 'is'. Still, any noticable stack mangling by Windows would make it almost impossible for the DOS programs to run correctly, I think.

As for why the fill command doesn't seem to be clearing the stack, I can't really say.

[Candy]

Simple guess: the debugger (debug) inserted an opcode after your mov so it could interrupt it after that one, that info was pushed on your stack so the bytes from FFEE and down (ffee and ffef are clear, check it) contain the stuff debug pushes. Note, it's the unused part of the stack, you shouldn't have used that.

[sulaiman]

i post this thread because i experience a weird stack after i execute my .com file.


problem.asm
=========

Code: Select all

org 100h

jmp   start

start:
   call   function_a
   jmp   finish

function_a:
   mov   bx,sp
   mov   ax,3
   mov   cx,4
   push   ax
   push   cx
   mov   sp,bx
   ret

finish:
   mov   ah,4ch
   int 21h

ok, the problem occur after you trace the RET statement.
eventually, the pushed values, 3 and 4 will be erased by so called -> stray windows

because I expect 3 and 4 to be remained in stack area because i already MOV SP,BX, where stack pointer already got the address to go back to the instruction JMP finish.

try FASM this code and trace the instructions to see the weird on your own.

[Candy]

Your stack that is before your stack pointer is by definition - NOT IN USE, and FOR FREE USE BY SOFTWARE & HARDWARE INTERRUPTS. Never Ever Ever use it for variables (or in c++, classes).