[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 

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