Hello,

i have got some problems to find an error in my program. The error occurs after serveral hours of normal working . How can i find the place in my program where the error could be ? I have compiled the program with the -gl switch but i got no output.I used the redir.exe for redireting the output because i am working in vesa graphic mode (graphix).
The error is an Page fault always at the same address: Page fault Cr2 = 10065e7c in RMCB at eip = 20e2.

Another error is an unknown runtime error :083
What does it mean ?

Thanks in advance.

Dirk Verwiebe

At 14:41 25/09/00 , vous avez écrit:

This usually means that a real interrupt is redirected into protected code by the program.
If this is a hardware interrupt, all code and data must be locked and a special selector must be used instead on the usual one. (see api/go32v2/mouse.inc for an example)

The problem is that this kind of error is only visible in true Dos, because under Win9X the page fault never occurs and the system loads the page into memory if it was not locked and is needed.

I think you are right, it seems to be the serial part of the program. Without accessing the serial port the program doesn´t crash.

I had a look into mouse.inc and it is a lot of assembler code and looks very difficult.
Have i to lock every variable which are used in the interrupt function ? Maybe it is enough to lock the code of the isr and the data buffer where the transfered bytes are stored ?
The registers are saved by the keyword interrupt ?

Const Ktr: Byte = 0; {These are STATIC variables so pascal doesn't } IIR: Byte = 0; {constantly have to redeclare them on the heap}

Procedure COM_ISR; Interrupt;
Begin
asm
cli
movw %cs:our_ds,%ax
movw %ax,%ds
movw %ax,%es
movw dosmemselector,%ax
movw %ax,%fs

     end;

......

   port[$20]:= $20;  {We're done processing the interrupt}
   asm sti end;
end;

I use the async unit from the fpc unit page(Hristo Chilingirov).

Thanks for your help.

Dirk Verwiebe

At 23:03 25/09/00 , vous avez écrit:

This will not work correctly for at least two reasons :
1) our_ds is not locked !
2) our_ds selector's limit is put to $fff
each time a real time interrupt (like keyboard interrupt) is triggered and needs to be reflected into a protected mode signal. For example pressing Ctrl-C does this.

Thus you should use
movw %cs:v2prt0_ds_alias,%ax
But don't forget to also lock this address

   lock_data(v2prt0_ds_alias,sizeof(longint));

mouse.inc uses the entry value of the es register which is the value given for the structure that contains the real mode registers at entry of the protected mode function called by the Real Mode CallBack.

You should read carefully the DPMI specification of the RMCB function (in Ralph Brown interrupt list for instance)

Antwort auf Mail von Pierre Muller vom 26.09.00 08:20:38:

Hello Piere,

thank you very much for your fast response.

Now i have another problem with the compiler.
If i try :

v2prt0_ds_alias:word; external name '___v2prt0_ds_alias'; i get an error:

Syntax error, : expectet but NAME found.

It seems the compiler doesn´t know external name. Is there a compiler switch for this keywords ?

regards
Dirk Verwiebe

At 14:01 26/09/00 , vous avez écrit:

What version of Free Pascal are you using ??

I tested this with version 1.0 and it works !

Beware that you can only use this with individual vars

ds,

   ds_alias : word;extenal name '___v2prt0_ds_alias';

must fail (but I get another error message for this !)

You are probably using mode TP or Delphi
(either with -So or -Sd or inside the source with

  {$mode TP} or

{$mode delphi} )
In these modes this syntax is not allowed and thus external is consodered as a normal variable name !

What version of Free Pascal are you using ??

I use the 1.1 Snapshots. The page faults are with 1.0 release and 1.1 snaps.

You are right again, the unit is compiled with {$mode tp}

I changed this switch against {$objfpc} but the unit didn´t compile anymore. I don´t know why. Unexpected end of file is the error message. At the end of the unit is a intitialising part with begin
.....
end.

The author of this async unit uses objects for the communication so i don´t know whether the unit is still working with other switches.

Is there another way to use this selector without crashes ?

greetings

Dirk Verwiebe

You are right again, the unit is compiled with {$mode tp} I changed this switch against {$objfpc} but the unit didn´t compile anymore.

Don't use OBJFPC, use standard FPC mode. OBJFPC is Delphi with FPC extensions.

He probably uses nested comments. Turn on warnings (-vw).

Jonas

Subject: Re: [fpc-pascal]Debuging in Freepascal

Pierre Muller schrieb: > What version of Free Pascal are you using ??

[....]

You could try to store the cs register into ds and es since with go32v2 cs = ds = es. So little code like

movw %cs, %ax
movw %ax, %ds
movw %ax, %es

should be fine instead of the

movw %cs:our_ds, %ax
movw %ax, %ds
movw %ax, %es

etc. stuff.

This saves you the lock/unlock stuff for the v2prt0_ds_alias too.

Note that it may not work in the callback though it is probably worth a try.

greetings Dirk Verwiebe

Regards,
Thomas

At this time i am using the dpmi unit from Thomas Schatzl. There is a function DSEGALIAS which should make the stuff with the v2prt0_ds_alias, i hope.

our_ds:=dsegalias;

and lockdata(our_ds). (Not in the ISR)

If this fails i try the code from above.

Is it possible to test my changes in a faster way ? The page fault occurs after 4-5 hours. So i only can test two times in a day my changes. And how can i be shure that the async unit is the problem ? Address from error message ?
Can i catch the page fault so that the program doesn´t stop?

greetings

Dirk Verwiebe

You could try to allocate a huge amount of memory (more than your real RAM) in your program and do random accesses to it. So the DPMI server has to swap and the chance for a page fault becomes higher.

Are you sure this works ?

cs and ds selector have the same base address
(the base address is the offset added to the address to get a linear address) but the permission are different !

I think that normally you are not allowed to write with the cs selector !

Does the dpmi server swap if not all physical memory is used ? I have in my target system 8 MB of Ram and only use ca. 2 MB.

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

It shouldn't but who knows.

system 8 MB of Ram and only use ca. 2 MB.

Do you have some kind of disk cache (smartdrv) or ramdisk installed? Afaik, a page fault is caused by a page moved to disk (or by accessed to non allocated memory addresses). Under certain circumstances (in an interrupt handler) the DPMI server can't fetch the page to the main memory and it issues a page fault.

Subject: Re: [fpc-pascal]Debuging in Freepascal

don´t

=

It doesn't depend on the use of the cs segment register but on the descriptor's access rights.

But you're right that it won't work - because my assumption is simply wrong, I've checked it.

I was trapped by remembering to have done some fpc program which self-modifies its' code - but I didn't remember that the code change was done via ds not cs.... :(

Well, the v2prt0_ds_alias or the use of the dsegalias()-function should work...

Regards,
Thomas

Who want subj? Please:

function cnhDiskInfo(Drive: Byte; var AAvailClusters, ATotalClusters,
  ABytesPerSector, ASectorsPerCluster: Longint): Boolean;
type
  TFSInfoBuf = packed record
    filesysid: ULONG;
    sectornum: ULONG;
    unitnum: ULONG;
    unitavail: ULONG;
    bytesnum: USHORT;
  end;
var
  fsInfoBuf: TFSInfoBuf;
  rc: APIRET;
begin
  AAvailClusters := -1;
  ATotalClusters := -1;
  ABytesPerSector := -1;
  ASectorsPerCluster := -1;
  Result := False;
  rc := DosQueryFSInfo(
    Drive,
    FSIL_ALLOC,
    fsInfoBuf,
    SizeOf(fsInfoBuf)
  );
  if rc  NO_ERROR then
    Exit;
  AAvailClusters := fsInfoBuf.unitavail;
  ATotalClusters := fsInfoBuf.unitnum;
  ABytesPerSector := fsInfoBuf.bytesnum;
  ASectorsPerCluster := fsInfoBuf.sectornum;
  Result := True;
end;

Question?

Well, the v2prt0_ds_alias or the use of the dsegalias()-function should work...

With the dsegalias() function and locking the selector the ISR is working.

Thank you all for your support.

greetings

Dirk Verwiebe