[fpc-devel]FW: Help! Walking stack causes GPF?
Thomas Schatzl
tom_at_work at yline.com
Thu Sep 14 17:26:50 CEST 2000
My suggestion is the following:
Change the
pnt := pointer(longint(@stack)+dimst-4);
// @stack returns the address of the 'stack' pointer
// this is somewhere in data segment
to
pnt := pointer(longint(stack)+dimst-4);
// now really points to the last bytes in 'stack'
// because the contents of 'stack' is where it is supposed to go
and try again.
Probably I'm totally wrong about this issue however and mixing it up
alltogether. You never know....
Please enlighten me if it is the case ;)
Regards,
Thomas
----- Original Message -----
From: "Alexander Stohr" <AlexS at s3.com>
To: <fpc-devel at deadlock.et.tudelft.nl>
Sent: Thursday, September 14, 2000 2:15 PM
Subject: RE: [fpc-devel]FW: Help! Walking stack causes GPF?
> 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
> >
>
> _______________________________________________
> 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