Recent

Author Topic: Windows 10 and FormClose  (Read 22811 times)

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Windows 10 and FormClose
« on: June 24, 2019, 06:17:51 pm »
I am using the following code for a very simple program. In WinXP it always worked, but not now in Win10. I have several other programs that are complicated, and they use similar or same code, but they work fine in Win10. I can't understand what is happening with this particular program.

When closing the App under development it gives an assembler idiv error. If compiled, Windows gives a "divide by zero" error. There isn't anything that divides by zero, and again, it doesn't happen in WinXP.

Code: Pascal  [Select][+][-]
  1. procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
  2. begin
  3. CloseAction:= caFree;
  4. (* // alternately for mechanical choice...
  5. if MessageDlg('Close application?', mtConfirmation, [mbYes, mbNo], 0) = mrYes
  6.    then CloseAction:= caFree
  7.    else CloseAction:= caMinimize;
  8. *)
  9. end;
  10.  
  11. procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: boolean);
  12. var CfgFile: TextFile;
  13.     DatStr: string;
  14.     OK: boolean;  // DatOK: boolean;
  15.     IOval: integer;  // longint;
  16. begin
  17. AssignFile(CfgFile, PrgmFolder+'CmdRPN.cfg');
  18. {$I-} Rewrite(CfgFile) {$I+};
  19. IOval:=IOresult; OK:=(IOval=0);
  20. if OK then   // was DatOK
  21.    begin try
  22.          Str(Reg0,DatStr); Writeln(CfgFile,DatStr);  // register display
  23.          Str(Reg1,DatStr); Writeln(CfgFile,DatStr);
  24.          Str(Reg2,DatStr); Writeln(CfgFile,DatStr);
  25.          Str(Reg3,DatStr); Writeln(CfgFile,DatStr);
  26.          Str(Reg4,DatStr); Writeln(CfgFile,DatStr);
  27.  
  28.          Str(Mem1,DatStr); Writeln(CfgFile,DatStr);  // storage memory
  29.          Str(Mem2,DatStr); Writeln(CfgFile,DatStr);
  30.          Str(Mem3,DatStr); Writeln(CfgFile,DatStr);
  31.          Str(Mem4,DatStr); Writeln(CfgFile,DatStr);
  32.          Str(Mem5,DatStr); Writeln(CfgFile,DatStr);
  33.          Str(Mem6,DatStr); Writeln(CfgFile,DatStr);
  34.          Str(Mem7,DatStr); Writeln(CfgFile,DatStr);
  35.          Str(Mem8,DatStr); Writeln(CfgFile,DatStr);
  36.          Str(Mem9,DatStr); Writeln(CfgFile,DatStr);
  37.  
  38.          Str(Dsp,DatStr); Writeln(CfgFile,DatStr); // decimal display
  39.          if HrsMode=true then DatStr:='1'  // HmsMode ...Dms
  40.                          else DatStr:='0'; // HrsMode ...Dec
  41.          Writeln(CfgFile,DatStr); // angle mode
  42.  
  43.          finally
  44.          Flush(CfgFile);
  45.          CloseFile(CfgFile);
  46.          CanClose:= true;
  47.          end;  // end try
  48.    end
  49.    else  begin
  50.          CloseFile(CfgFile);
  51.          CanClose:= false;
  52.          end;
  53. end;
  54.  
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

ASerge

  • Hero Member
  • *****
  • Posts: 2222
Re: Windows 10 and FormClose
« Reply #1 on: June 24, 2019, 07:44:19 pm »
With debugging information, you can get a stack trace to find the code that generates the error.

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Windows 10 and FormClose
« Reply #2 on: June 25, 2019, 02:05:01 pm »
Thanks ASerge,

Assembler Error without debug:
00452FB2 f7f9      idiv   %ecx

With debug active:
raised exception class 'External: SIGFPE'.
At address 452FB2

With backtrace active:
In file 'lclproc.pas' at line 902

source://C:\Lazarus\fpc\3.0.2\source\rtl\win32\system.pp(16,1)

Code: Pascal  [Select][+][-]
  1. procedure RaiseGDBException(const Msg: string);  // *lclproc.pas*
  2. begin
  3.   debugln(rsERRORInLCL, Msg);
  4.   // creates an exception, that gdb catches:
  5.   debugln(rsCreatingGdbCatchableError);
  6.   DumpStack;
  7.   if (length(Msg) div (length(Msg) div 10000))=0 then ;   // *line 902*
  8. end;
  9.  

The first time that I used debug on this I did not get any error.
I switched debug off and ran it, and it produced the former error.
I switched debug on again, and it gave the above data.

I don't know what to do with what I am looking at.

I also have compiler version 2.0.2, and it gives this error also.
« Last Edit: June 25, 2019, 02:07:10 pm by rick2691 »
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Windows 10 and FormClose
« Reply #3 on: June 25, 2019, 02:30:20 pm »
I just went back to vers 2.0.2. Now it is not creating the error. I also activated debugging, and no error.

Formerly, with the 1.6.4 version operating as compiled app, I was getting crash frequently but not always.
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Windows 10 and FormClose
« Reply #4 on: June 25, 2019, 02:46:50 pm »
Code: Pascal  [Select][+][-]
  1. if (length(Msg) div (length(Msg) div 10000))=0 then ;   // *line 902*
  2. end;

This goes wrong if length(msg) div 10000=0

Which is true for anything under 10000. So the code is simply wrong.
Check your divisors for divide by zero.

In some cases external libraries (including video card drivers via their opengl implementation, if you USE that) can toggle  the default state to ignore, but it remains incorrect.

Keep in mind: Working code does NOT mean correct code, and it is pointless to linger on why incorrect code sometimes works and sometimes not. Just correct the code.

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Windows 10 and FormClose
« Reply #5 on: June 25, 2019, 03:03:01 pm »
Thanks Marcov,

It only crashes when exiting the program. That is why I posted the exit handlers that I am using. There is no division at all.
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

rvk

  • Hero Member
  • *****
  • Posts: 6111
Re: Windows 10 and FormClose
« Reply #6 on: June 25, 2019, 03:15:18 pm »
Code: Pascal  [Select][+][-]
  1. if (length(Msg) div (length(Msg) div 10000))=0 then ;   // *line 902*
  2. end;
This goes wrong if length(msg) div 10000=0
Which is true for anything under 10000. So the code is simply wrong.
Check your divisors for divide by zero.
No, the code is not wrong. The division by zero is very intentional. It's in RaiseGDBException where the code forces an exception because of something.

The real code is in laztracer.pas (in components/lazutils) and reads like this:
Code: Pascal  [Select][+][-]
  1. procedure RaiseGDBException(const Msg: string);
  2. begin
  3.   DebugLn(lrsERRORInCode, Msg);
  4.   // creates an exception, that gdb catches:
  5.   DebugLn(lrsCreatingGdbCatchableError);
  6.   DumpStack;
  7.   {$ifndef HASAMIGA} // On Amiga Division by 0 is not catchable, just crash
  8.   if (length(Msg) div (length(Msg) div 10000))=0 then ;
  9.   {$endif}
  10. end;

So nothing to do with an actual division by zero but just code to make it crash intentionally.

But you are correct about working code does not mean correct code. There is still some error somewhere.
Best way to find it is debugging and stepping through the code.
Set some Showmessage at certain points and see if the code reaches it.
Or use F5 to set breakpoints and use the debugger.

If the program only crashes at the end you'll need to strip the code. For example strip the complete CloseQuery and see if it makes a difference. If not, strip some other code until you don't receive the error on exit.
« Last Edit: June 25, 2019, 03:18:12 pm by rvk »

nanobit

  • Full Member
  • ***
  • Posts: 160
Re: Windows 10 and FormClose
« Reply #7 on: June 26, 2019, 11:47:02 am »
Rick, you seem to be under win32,
for better debugging with system exceptions (SIGFPE, ...) you can use win32Veh.pas from:
https://forum.lazarus.freepascal.org/index.php/topic,44905.0.html


Thaddy

  • Hero Member
  • *****
  • Posts: 14202
  • Probably until I exterminate Putin.
Re: Windows 10 and FormClose
« Reply #8 on: June 26, 2019, 12:27:32 pm »
Rick, you seem to be under win32,
I would be very, very surprised if that was the case. He's on many platforms and always takes the time to test.
He's most certainly not on abandon ware. (win32) by default.
Reasoning: in the Netherlands and Belgium Win32 is only available on special request or as a Microsoft certified developer with an MSDN subscription: There is not a distribution for Win32 *at all* apart from such request or an professional MSDN account. In the low lands Win10 = 64 bits, usually.

Maybe you mean he is compiling for 32 bits? Which is supported in this last win 10.1 version but will be dropped from newer major Windows than 10. Just like Apple's OSX did.

https://en.wikipedia.org/wiki/Up_to_eleven  8) :P :P
« Last Edit: June 26, 2019, 12:35:59 pm by Thaddy »
Specialize a type, not a var.

nanobit

  • Full Member
  • ***
  • Posts: 160
Re: Windows 10 and FormClose
« Reply #9 on: June 26, 2019, 12:35:39 pm »
Thaddy, I referred to rick2691, signature and his 2nd post:
"With backtrace active: In file 'lclproc.pas' at line 902
source://C:\Lazarus\fpc\3.0.2\source\rtl\win32\system.pp(16,1)"
But you know better.... :)

rvk

  • Hero Member
  • *****
  • Posts: 6111
Re: Windows 10 and FormClose
« Reply #10 on: June 26, 2019, 12:36:29 pm »
Reasoning: in the Netherlands and Belgium Win32 is only available on special request or as a Microsoft certified developer with an MSDN subscription: There is not a distribution for Win32 *at all* apart from such request or an professional MSDN account. In the low lands Win10 = 64 bits, usually.
That doesn't mean development itself can't be in Win32 for Lazarus/FPC.

In fact, looking at the signature of Rick, i386-win32 is still included in the mix.
Quote
Windows 10, LAZ 1.6.4, FPC 3.0.2, SVN 54278, i386-win32-win32/win64, forms use windows unit

Edit: Ah, and @nanobit also saw the source-code path (as win32).

rvk

  • Hero Member
  • *****
  • Posts: 6111
Re: Windows 10 and FormClose
« Reply #11 on: June 26, 2019, 12:40:13 pm »
Maybe you mean he is compiling for 32 bits? Which is supported in this last win 10.1 version but will be dropped from newer major Windows than 10. Just like Apple's OSX did.
Yikes, I wonder when that will be (actual date).
I'm still under Delphi 32bit for my commercial program and wasn't planning on switching soon.

Thaddy

  • Hero Member
  • *****
  • Posts: 14202
  • Probably until I exterminate Putin.
Re: Windows 10 and FormClose
« Reply #12 on: June 26, 2019, 12:41:39 pm »
still, my post has some value: win32 is 0.5% or less of the licenses (According to microsoft) and compiling for 32 bit windows is abandon ware. (or silly!)
Specialize a type, not a var.

rvk

  • Hero Member
  • *****
  • Posts: 6111
Re: Windows 10 and FormClose
« Reply #13 on: June 26, 2019, 12:44:25 pm »
<slightly off topic>
About 50% of my customers still run computers with 32bit OS versions on it (ranging from XP, few, to Windows 7 majority). Although Windows 7 might be out of support it's still used a lot.

I guess I need to look into compiling and maintaining two versions then.
</slightly off topic>

Thaddy

  • Hero Member
  • *****
  • Posts: 14202
  • Probably until I exterminate Putin.
Re: Windows 10 and FormClose
« Reply #14 on: June 26, 2019, 12:44:51 pm »
Maybe you mean he is compiling for 32 bits? Which is supported in this last win 10.1 version but will be dropped from newer major Windows than 10. Just like Apple's OSX did.
Yikes, I wonder when that will be (actual date).
I'm still under Delphi 32bit for my commercial program and wasn't planning on switching soon.
There was an announcement on the MSDN blogs and an accompanying email if you are subscribed.
Will take some time, but the next major number release (11?) will be 64 bit only on Intel.

Didn't you know that?

BUT there is LTS support until 2024 for Windows 10.

Btw, apologies for confusing Rik's with Rick's.... :o :( :(
Specialize a type, not a var.

 

TinyPortal © 2005-2018