Inconsistency between Windows and Linux compiling?

[Alex Kidd]

I began experimenting with Lazarus, using Moraz Abdel Azeem's Start programming using Object Pascal.

I stumbled upon this issue compiling this simple program (excerpt):

Code: [Select]

var
  x,y:integer;
  res:double;
begin
  x:=5;
  y:=0;
  try
[color=red]    res:=x/y;[/color]
  except on e:exception do
      writeln('Exception:',e.message); [actually, I'm using a Memo]
  end;

  writeln('Res:',floattostr(res));  [actually, I'm using a Memo]
end;                                    

If I compile and run this code in Windows, a DivideByZero exception is raised, which is correct.  
On the other hand, if I compile and run this code in Linux, no exception is raised: the variable res is set to "+inf" value.  

Is there a particular compiler flag I have to set in Linux to obtain the correct behaviour?

Please, let me know!

[eny]

If I compile and run this code in Windows, a DivideByZero exception is raised, which is correct. 

What Lazarus and FPC version?
When I do this the program crashes horribly.
(BTW: dividing through zero is not the best of ideas...)

[Alex Kidd]

If I compile and run this code in Windows, a DivideByZero exception is raised, which is correct. 

What Lazarus and FPC version?
When I do this the program crashes horribly.
(BTW: dividing through zero is not the best of ideas...)

Lazarus 0.9.30 and FPC 2.4.2.
I agree "divide by zero" is not the best of ideas  , I was just trying the samples in the book and make a comparison between Linux Mint 10 and Windows XP SP3 to verify the behaviour is exactly the same.

Apparently they differ: WinXP raises the exception, while Linux says the result is +Infinite.

This means in this particular case I cannot write the code once and compile everywhere. I think this is normal when coding using DLLs or OS specific features, but not when using simple math functions.

 

[Zoran]

Alex, what output do you get from this program if exception doesn't get raised?

I have just tried and compiled this example on Linux (Ubuntu 11.04). The exception gets raised as expected.
When I enter zero for y, I receive the message "An error occurred: Division by zero", which means that the execution fell into "except" branch of try-except block.

Further, if I change the writeln to

Code: [Select]

Writeln('An error occurred: ', e.ClassName, ' - ', e.message); (that is, add e.ClassName to output), I can see that EDivByZero got raised (I get: "An error occurred: EDivByZero - Division by zero").

[Blaazen]

Here I also get:

Code: [Select]

Res:+Inf
I think it is correct because "/" is used and "res" is double.

If I replace "/" with "div" project gives SIGFPE - invalid floating point operation.
It is also correct because result of "div" cannot be +Inf and therefore there is no result which can be assigned to "Res".

[Alex Kidd]

Blaazen, which Linux distro are you using?

It seems you and Zoran are experimenting different outputs. I tried also Mint 11, and still I get the +inf behaviour (with no exception).

I get the SIGFPE error too when using DIV instead of "/" (the exception is EInvalidOp, Invalid floating point operation). 

Zoran, what disto / fpc version are you using by the way?

I think something strange is going on here... 

[Alex Kidd]

Well, maybe the title I used in the topic is incorrect. I think I found out the difference is not between the Linux and WinXP version, but between "Application" and "Program".

The application shows the +inf behaviour, while the program behaves like Zoran's test.

Here are the two codes:
APPLICATION

Code: [Select]

unit Unit1;
{$mode objfpc}{$H+}
interface
uses
 Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls;
type
  { TForm1 }
  TForm1 = class(TForm)
    Memo1: TMemo;
    procedure FormCreate(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;

var
  Form1: TForm1;

implementation
{$R *.lfm}
{ TForm1 }

procedure TForm1.FormCreate(Sender: TObject);
var
  x,y:integer;
  res:double;
begin
  x:=5;
  y:=0;

  try
    res:=x / y;
  except on e:exception do
    memo1.append(e.message);
  end;

  memo1.append(floattostr(res));
end;
end.              


PROGRAM

Code: [Select]

program Project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes,sysutils
  { you can add units after this };

{$R *.res}

var
  x,y:integer;
  res:double;

begin
  x:=5;
  y:=0;

  try
    res:=x / y;
  except on e:exception do
    writeln(e.message);
  end;

  writeln(floattostr(res));
end.      

Later on I'm going to reboot to winxp and test if my theory is confirmed (i.e. I was really wrong suspecting Lin and Win compile differently...  ).

[Alex Kidd]

Back on line.

I tested the two codes in WinXP and I always got the Divide By Zero exception.

My suspect is that in the Application version in Linux Mint 10 and 11 (and the distro used by Blazeen) the compiler somehow think 5/0 is a valid operation, and the risult is +inf.

Help!!!   

[Blaazen]

My first attempt was in Chakra (Arch-based linux). I rebooted to Kubuntu with the same result (Res:+Inf). (both are 64-bit)

Then I tried compile it without Lazarus from console (fpc filename.pas - without compiler options). I tried both as program and as unit - both gives Division by Zero.

So it is not distro related. It must be some special compiler option which Lazarus uses but I don't know which, they are so many.

[Bart]

Might have something to do with the exceptionmask (unit math)?

Bart

[Laksen]

It's probably libraries of the host system that are overriding the exception mask, as Bart suggests. If it's a big problem then include the math unit, and in the start of the program do SetExceptionMask([]);

[Alex Kidd]

It's probably libraries of the host system that are overriding the exception mask, as Bart suggests. If it's a big problem then include the math unit, and in the start of the program do SetExceptionMask([]);

I tried the SetExceptionMask suggestion and it works 

Thank you so much to all users who kindly answered my question.

Lazarus is a fantastic project and I think it's gonna replace very soon Java, Mono and Python for my cross-platform needs (especially the GUI related). I just need to experiment some more.

In the meanwhile I'm spreading the voice with my colleagues, showing the capabilities of Lazarus. A couple of Delphi nostalgic didn't even know there was an open source project going on and now are thanking me for the hint!

[Zoran]

What is actually this ExceptionMask?
I can't find anything in documentation.
And I think that this diferrent behavior is not a minor thing, I realy would like to understand what it is about.

[Laksen]

The exception mask is the mask for exceptions coming from the FPU

So if it's entirely unmasked(as is the default for FreePascal) all exceptional behaviour will generate an exception. However if it's masked, either entirely or partly(as is the default for some C programs), the operation will go unnoticed: 1/0 will become +Inf, log(0) will be NaN, etc

The FreePascal RTL does clear this exception mask when the program starts, but if the program subsequently loads DLLs or SOs that override the exception mask for the process then the program won't be notified. And it can go the other way too. Some C DLL/SOs might "randomly" generate exceptions because they might rely on unsafe FPU operations

[Zoran]

It's probably libraries of the host system that are overriding the exception mask, as Bart suggests.

If I understand correctly, this means that if some library is called by the application and that library changes this exception mask for its own purposes, than the whole program will change its exception handling?!

If it's a big problem then include the math unit, and in the start of the program do SetExceptionMask([]);

Does not work. Setting the ExceptionMask to empty set in program start creates many new exceptions and the application crashes.

There are problems even if the ExceptionMask is set for this simple isolated line:

Code: [Select]

procedure TForm1.Button1Click(Sender: TObject);
var
  X, Y: Integer;
  Res: Double;
  FPUExceptionMask: TFPUExceptionMask;
begin
  X := StrToInt(Edit1.Text);
  Y := StrToInt(Edit2.Text);
  try
    FPUExceptionMask := SetExceptionMask([]);
    try
      Res := X / Y; // I set ExceptionMask only for this line of code
    finally
     SetExceptionMask(FPUExceptionMask); // and restore it back
    end;

    Label3.Caption := FloatToStr(Res);
  except
    on E: Exception do
      Label3.Caption := E.ClassName + ' - ' + E.Message;
  end;

end;
Now it raises EInvalidOp, when I use non-divisible integers, although the result is regularly stored in Double, something which works well if I do not mess with ExceptionMask (see the picture).