Hi,

when running a program interacting with a c library accessing the disc drive and writing some informational strings to "stderr" there are thrown

An unhandled exception occurred at $0804940D :
EInOutError : Disk Full

exceptions randomly all over the place. The line position in the program is constant but the amount of data processed is changing randomly. At some runs no exception source line is:

writeln(stderr, '--> hit found: '+inttostr(fcnt) + ' - ' + inttostr(PInteger(longint(adr)-longint(fx))^) + ' - ' + floattostr(PSingle(adr)^));

fx is an offset holding 33 and adr is a pointer into a block of memory alocated with getmem. The output is for debugging only.

The error is happening when only read calls are made to the underlying file.

If run in gdb the only message is:

Program exited with code 0331.

so no backtrace or the like.

Is there any debugging technique or some other information that can help me finding the cause?

If I use the heap trace unit (fpc -gh) the program fails at the first few lines, although apparently working correctly at that spot ... maybe a consequence of doing a lot pointer calculations.

Helpless regards,
Marc

Marc Santhoff wrote

Is there any debugging technique or some other information that can help me finding the cause?

Run the program through strace to see what the actual error is. Some unrelated error codes are also converted to "disk full" (such as EFAULT).

Jonas

Haha! ... I myself tell people to use it and if the row is at me, I've forgotten. :D

Thanks for reminding me,
Marc

Very nasty thing:

The output channel is temporarily blocked and gives back "EAGAIN".

This leads to exceptions thrown repeatedly which cannot be signaled because the output channel is blocked!

I'm changing my practice of using stderr for debugging output, that much is sure. I know try ... except-blocks would come in handy, but I had to disable them for debugging purposes.

Concluding I can say: fpc is too fast in writing for my computer! ;)

Marc

This means the output channel is opened non-blocking. Is that intentional or a bug ?

Micha

I guess the initialisation code of the system unit should close and reopen stdin/out/err to make sure none of them is configured for non- blocking I/O.

Jonas

Hm, I'm doing nothing but using an xterm for compiling and running the program. System.pp does only open as far as I can tell:

<rtl/inc/tex.inc>
...
procedure OpenStdIO(var f:text;mode,hdl:longint);
begin
  Assign(f,'');
  TextRec(f).Handle:=hdl;
  TextRec(f).Mode:=mode;
  TextRec(f);
  case mode of
    fmInput :
      TextRec(f);
    fmOutput :
      begin
        TextRec(f);
        if Do_Isdevice(hdl) then
          TextRec(f);
      end;
  else
   HandleError(102);
  end;
end;
...
</rtl/inc/tex.inc>
<rtl/bsd/system.pp>
...
procedure SysInitStdIO;
begin
  OpenStdIO(Input,fmInput,StdInputHandle);
  OpenStdIO(Output,fmOutput,StdOutputHandle);
  OpenStdIO(ErrOutput,fmOutput,StdErrorHandle);
  OpenStdIO(StdOut,fmOutput,StdOutputHandle);
  OpenStdIO(StdErr,fmOutput,StdErrorHandle);
end;

...

Begin
  IsConsole := TRUE;
  IsLibrary := FALSE;
  StackLength := CheckInitialStkLen(InitialStkLen);
  StackBottom := Sptr - StackLength;
  { Set up signals handlers }
  InstallSignals;
  { Setup heap }
  InitHeap;
  SysInitExceptions;
  { Setup stdin, stdout and stderr }
  SysInitStdIO;
  { Reset IO Error }
  InOutRes:=0;
  { Arguments }
  SetupCmdLine;
  { threading }
  InitSystemThreads;
  initvariantmanager;
  initwidestringmanager;
End.
</<rtl/bsd/system.pp>>

Maybe it is an OS fault(?) ...

Marc