Hi, folks!
i've received following email and decide to forward it to mailing list. as you'll understand, you'll need answer it directly into email of that guy, instead of mailing list.
-----FW: -----
Date: Wed, 13 Sep 2000 14:06:58 +0000
Sender:
From: startx
To:
Subject: Help! Walking stack causes GPF?
Hi,
I am getting into serious troubles with my work (and my boss). Please help me!
I've tried to mail the fpc mailing list, but my SMTP server refuses to send... don't know why - so excuse me if I write to you directly.
I am writing a pseudo multitasking application under free-pascal/DOS (go32), as I need the equivalent of cooperative multitasking.
The idea I've took is simple: every program to be multiplexed is put in a unit, and the inizialization part only contains a call to a registering function:
Unit something;
interface
implementation
Uses .....
procedure MAIN;
begin
...
Multiplex; // call to let other pseudoprograms run
...
Multiplex;
...
end;
begin // initialization
addapplic('SOMETHING',@main,16384)
end.The last line adds a record in a linked list which records the name, entry-point and stack size.
When this unit has to be run, a procedure is called which getmem() the stack, puts a termination address, then the address of the procedure MAIN above, a suitable EBP and then exits normally. This has the effect of jumping at MAIN with a new stackframe. This procedure "Newtask" also appends a new slot for the scheduler.
with thisnewtask^ do begin
getmem(stack,dimst);
pnt := pointer(longint(@stack)+dimst-4); // point to last
doubleword of this stack
pnt^ := @TerminateProg; // push the address of a
termination routine (cleanup)
dec(longint(pnt),4);
pnt^ := entrypoint; // push the address of
the newly created thread
dec(longint(pnt),4);
pnt^ := pointer(longint(@stack)+dimst); // ESP of this new
process
pbp := pnt; // every process has a pbp member, which points
into its stack
end;When procedure Multiplex is called, it searches for a new slot, then moves the BP of the new process into the 'real' EBP and returns. This jumps where that process was left over, which the same stack:
// save the stackframe of the calling pseudoprocess...
asm
mov edi,Actprog // ActProg points to infos aboutthe current process
mov [edi].TProgram.pbp,ebp // which is about to be suspended right now
end; // search for the next process to time-slice...
...
// found. Now Actprog points to the new process
asm
mov edi,Actprog
mov ebp,[edi].TProgram.pbp // another stack is now ineffect
endNow, everything works just fine, but the program runs for some minute, and then does a GPF. I'm pretty sure the code is OK (no memory overwrites and the like), so I suspect this 'walking stack' cause some other problem. Often the program crashes when trying to allocate or fremem() some memory. When it tries to do a getmem(apointer,8192), nothing can be wrong in the code, right? As long as the pointer 'apointer' resides somewhere in the DS segment, nothing should go wrong. Well, often (but not always) the program give me this GPF. Even the errors are not always the same... nor the point in code and nor the moment. May be the program lasts just one minute, or ten. There are *never* other kinds of problems (which could make me suppose my code has bugs).
I have also to add that it seems that in a Linux dosbox everything (ppc386, gdbpas) works better (I tried to debug the code, but often gdbpas hangs the machine in true dos; it never hangs in a linux dosbox (dosemu).
This leads me to think there's something wrong, or something I should know, about CWSDPMI.EXE. I have also tried to lock_data in the stack, but seems nothing changes. Often happens that I compile the above program, put a breakpoint somewhere, and run it: the computer locks.
From that point, the same executable becomes undebuggable - if any
breakpoint is set (even *before* the stack trick), using either IDE or gdbpas, everything locks. So it is hard to debug, sometimes. If I try to debug in a Linux box, I succed, but it is too slow (graphics...) to work comfortably.
Last thing to add: I use Graph, and do an int $33 to poll the mouse. No other strange things are done. It seems also that in a win98 command prompt, instead of pure dos, things get slightly better (but not so much).
I can email the entire source (it is a little long indeed), if requested.
Again, please help me - I have no more than a week, and after then I must face my boss and our customer...
Thank you.
Doriano Bengino
--------------End of forwarded message-------------------------
---
with best regards, Romio "Lucky" Pedchenko :) //
look here: http://clc.uch.net/ftn/fidosoft.html