RaiseGDBException "Division by zero"

[JZS]

http://forum.lazarus.freepascal.org/index.php/topic,34604.msg259956.html#msg259956


While trying to use NiceGrid ported from Delphi, it works fine (so far) except the 'External: SIGFPE' when closing the project. Even before changing anything, with non-modified dropped NicGrid component on an empty form, when compile and closing the form, it errors out.

 In file 'lclproc.pas' at line 916:
if (length(Msg) div (length(Msg) div 10000))=0 then ;

What could raise such errors? I tried going through the code but could not identify what could be needs to be changed to silent that error.

Hope someone has hit that point and managed to fix it.

This component has been added to fpGUI of Graeme's by Jean Pierre Anghel, do not know what he did to fix that.

Appreciate any support.

Laz1.8rc4 - Win7

[molly]

Ok, so let me try to get this straight.

You have the following statement...

Code: [Select]

if (length(Msg) div (length(Msg) div 10000))=0 then ;
Which throws you a division by zero ...

And you don't have any idea why that happens ?

* molly thinks you just answered your own question ?

[JZS]

Hi molly,

That was not my code. That is the error line in Lazarus (unit lclproc.pas) when I close my form.

That unit is not used directly by me, it is used by NiceGrid Component through the unit PropEdits.

[balazsszekely]

To find out the cause you need to create a backtrace: http://wiki.freepascal.org/Creating_a_Backtrace_with_GDB.

[molly]

That was not my code. That is the error line in Lazarus (unit lclproc.pas) when I close my form.

That unit is not used directly by me, it is used by NiceGrid Component through the unit PropEdits.

hmz, seems i'm really getting issues with my vision as i overlooked the lclproc part. That's the second one i missed t'day Sorry for that.

The gist of it stands though... but of course you already knew that.

As Getmem suggested a backtrace would be very welcome.

[J-G]

Am I missing something VERY obvious ??

That equation can only have two answers - 10000 and 0 (zero) - and if it is zero (when length(msg) is zero) then of course it will raise a "Division by zero" error. 

[molly]

@J-G:
Exactly my initial thought when i posted my first reply 

Alas, the exception occurs inside lclproc which suggests that TS is not responsible (well, not directly that is) as TS uses another component that seems to cause the exception. So either there is a oversight/flaw with the used component or TS is doing something 'really fishy'.

Right now it's hard to tell what exactly is the culprit. A back-trace would be able to tell the path of the code, thus what code exactly is responsible. If indeed the component then this will show as well, and hopefully also pinpoint the location.

[J-G]

@J-G:
Exactly my initial thought when i posted my first reply 

Alas, the exception occurs inside lclproc which suggests that TS is not responsible (well, not directly that is) as TS uses another component that seems to cause the exception. So either there is a oversight/flaw with the used component or TS is doing something 'really fishy'.

Right now it's hard to tell what exactly is the culprit. A back-trace would be able to tell the path of the code, thus what code exactly is responsible. If indeed the component then this will show as well, and hopefully also pinpoint the location.

Whilst I understand that the cause of the error - which I posit is the fact that the length of (msg) can be zero - the logic of the statement is surely flawed ie. it MUST create a DIV-0 error. The length of (msg) could be trapped elsewhere and this statement never called in such a case but then the result has to be 10000 so what is the purpose?

Just curious

[molly]

...
the logic of the statement is surely flawed ie. it MUST create a DIV-0 error. The length of (msg) could be trapped elsewhere and this statement never called in such a case but then the result has to be 10000 so what is the purpose?

Yes indeed, that is a very valid point. Developers implementations sometimes works in mysterious ways ? 

I haven't located the offending code yet (it'll have to wait till i'm home), but fwiw i have the same curiosity...

[molly]

Nah, what the heck. I had nothing to do during my cuppa tea 

903   {------------------------------------------------------------------------------
904     procedure RaiseGDBException(const Msg: string);
905   
906     Raises an exception.
907     Normally gdb does not catch fpc Exception objects, therefore this procedure
908     raises a standard "division by zero" exception which is catched by gdb.
909     This allows one to stop a program, without extra gdb configuration.
910    ------------------------------------------------------------------------------}
911   procedure RaiseGDBException(const Msg: string);
912   begin
913     debugln(rsERRORInLCL, Msg);
914     // creates an exception, that gdb catches:
915     debugln(rsCreatingGdbCatchableError);
916     DumpStack;
917     {$ifndef HASAMIGA} // On Amiga Division by 0 is not catchable, just crash
918     if (length(Msg) div (length(Msg) div 10000))=0 then ;
919     {$endif}
920   end;

When the context is into place, things are starting to make much more sense...

[J-G]

@ molly

Well done - the idea that a DIV-0 error couldn't be trapped escaped me 

The 10000 is purely arbitrary, it could just as easily be 10  -  or any other figure for that matter.

Further proof that provision of as much supporting code as possible (however unlikely the relevance seems) makes accurate advice/problem solution much easier.

[JZS]

To find out the cause you need to create a backtrace: http://wiki.freepascal.org/Creating_a_Backtrace_with_GDB.

Thank you GetMem
When you think you know it all, you just discover there is something you simple and useful you just missed.

It was this function:
procedure TNiceGrid.WMKillFocus(var Msg: TWMKillFocus);
begin
  if (Msg.FocusedWnd <> FEdit.Handle)
    then ForceHideCaret;
  DestroyCaret;
  CaretVisible := False;
  if not IsEditing
    then InvalidateCells;
end;

Once commented out it worked fine.

Thank you all.

[molly]

Indeed J-G.

That is also why GetMem has the better idea 

[Thaddy]

You may also have missed that on some platforms a division by zero can not throw an exception unless forced to do it. Some platforms simply return -inf. Which should be tested for and raised as exception by the programmer. E,g. AARCH64 (not the only one) ... Maybe I am over-complicating things, but just in case...

[J-G]

Maybe I am over-complicating things, but just in case...

Not at all Thaddy  -  very often the smallest detail is the one that trips you up, and I certainly wasn't aware that some platforms can't (don't bother to) trap Div-0. (not that I write for anything other than Windows )