[fpc-devel]FW: Help! Walking stack causes GPF?
Alexander Stohr
AlexS at s3.com
Thu Sep 14 14:15:08 CEST 2000
I got that mail too, replied on the topic
itself and added a few hints on how to
mail via GMX or hotmail if the personal
mail account has send malfunctions.
I supposed it might be either caused
by the mouse, by the special sort of
segment a stack represents or by some
code that is not capable of multi threading
regardless of cooperative or preemptive
multitasking.
I requested sufficient source for counterchecking
this myself on Win2k. No reaction until now.
> -----Original Message-----
> From: Romio [mailto:romio at mastak.com]
> Sent: Wednesday, September 13, 2000 23:31
> To: romio at iname.com
> Subject: [fpc-devel]FW: Help! Walking stack causes GPF?
>
>
> 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: <39BF8A02.3520B4DD at geocities.com>-----
>
> Date: Wed, 13 Sep 2000 14:06:58 +0000
> Sender: root at smv12.iname.net
> From: startx <startx at geocities.com>
> To: romio at iname.com
> 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', at 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 about
> the 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 in
> effect
> end
>
>
> Now, 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
> startx at geocities.com
> linuxfan at tin.it
>
> --------------End of forwarded message-------------------------
>
> ---
> with best regards, Romio "Lucky" Pedchenko :) // romio at mastak.com
> look here: http://clc.uch.net/ftn/fidosoft.html
>
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
More information about the fpc-devel
mailing list