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.This goes wrong if length(msg) div 10000=0
if (length(Msg) div (length(Msg) div 10000))=0 then ; // *line 902* end;
Which is true for anything under 10000. So the code is simply wrong.
Check your divisors for divide by zero.
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.
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.
Windows 10, LAZ 1.6.4, FPC 3.0.2, SVN 54278, i386-win32-win32/win64, forms use windows unit
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).
There was an announcement on the MSDN blogs and an accompanying email if you are subscribed.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.
<slightly off topic>WHY didn't they upgrade...? It was free (I don't know if it still is..) Government customers? Social sector? you know what I mean.
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>
WHY didn't they upgrade...? It was free (I don't know if it still is..)Until last year you could still upgrade (under the assumption you used the disabled-features which wasn't checked).
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.
Luckily I'm not responsible for their network environment %)Actually, morally, you are.... Accidents waiting to happen and then they blame your software......
With backtrace active:You should look at the stack trace earlier. This procedure is called to pass an error to the debugger, that is, an error has occurred before.
In file 'lclproc.pas' at line 902
source://C:\Lazarus\fpc\3.0.2\source\rtl\win32\system.pp(16,1)
procedure RaiseGDBException(const Msg: string); // *lclproc.pas* begin debugln(rsERRORInLCL, Msg); // creates an exception, that gdb catches: debugln(rsCreatingGdbCatchableError); DumpStack; if (length(Msg) div (length(Msg) div 10000))=0 then ; // *line 902* end;
In some cases external libraries (...) can toggle the default state to ignore
I was hoping that someone else would have had a similar issue and a quicker fixI don't have Problems with Closing, but with Resizing on Win10:
By excluding certain functions I am pretty sure that my problem is a "floating format" issue. The program is a calculator, so it also has trouble with the str(x:0:4) function. It appears that if "x" is nearly zero (ie. 1123E-240) it throws an exception.You can make an example? On my machine the following code is executed without problems with x32 and x64:
Why are you using empty finally blocks in try-finally-end? This is absolutely useless.Because the editor automatically kicks the 'finally' in. I leave them because I might need them later. They do any harm.
Code snippets like these are not very helpfulI have posted the code because ASerge asked me to.
I am asking for it, too. Having no compilable code often leads to endless discussions because everybody does and understands things a bit different.QuoteCode snippets like these are not very helpfulI have posted the code because ASerge asked me to.
@wpThe editor adds finally only if you introduce "try" yourself.QuoteWhy are you using empty finally blocks in try-finally-end? This is absolutely useless.Because the editor automatically kicks the 'finally' in. I leave them because I might need them later. They do any harm.
+1. With this piece of code the error does not reproduce.I am asking for it, too. Having no compilable code often leads to endless discussions because everybody does and understands things a bit different.QuoteCode snippets like these are not very helpfulI have posted the code because ASerge asked me to.
I tried the SetExceptionMask...It did not helpYou must put it at the very Beginning of the Program - Did You do so ?
The program is a calculator + I do not believe that these things are due to my codingI found a Calculator (normal-scientific-graphic) in my DelphiCode-Collection (see attached 'Calculator.7z').
It only crashes when closing the applicationDid You try out the HeapTrc-Unit (-gh Switch) to check Memory-Allocation/Deallocation ?
It has posted as an another thread with the same titleHope, You agree, that I copied Your Post from the other Thread over here to keep continuity:
@Cyrex
Can you be more specific about the trunk etc. What is its Web address? Is it many installs? What are their names. Where do you assign your script to effect your features?
You also need to launch from an exe. If you do it by run, it is protected.%)
I changed the above Close method to a code that is posted elsewhere on the forum.In fact, this makes my suspicions only bigger.
With no incompatibilities set, it raised an exception the same as before. When I set Win8 compatibility, it has not raised any exceptions ... for several attempts with testing. At present I am going to just wait and see.
I believe there is a slight flaw in how the IDE is destroying the form. By slight I mean that it happens here, and some have confirmed that it happens with them but for different reasons.The IDE isn't in question because you say it also happens when you run it outside the IDE (as release version). If it's something from Lazarus it would be the LCL-code itself.
It is some sort of floating garbage. It should be analyzed by the engineers. But I have appealed to them about other cases in the past. I do not intend to do so again.It can only be analysed when they can reproduce the error. That's the whole problem. You (with some of your other clients) are the only ones with this problem. We would be very (and I mean very very) happy to diagnose this problem if we could only reproduce it.
It can only be analysed when they can reproduce the error. That's the whole problem. You (with some of your other clients) are the only ones with this problem. We would be very (and I mean very very) happy to diagnose this problem if we could only reproduce it.I was also able to reproduce the error. Rarely, after a series of operations (in the program), and closing, performed quickly and on the keyboard. The error is the same as rick2691 pointed out. Here are my stats: reproduce on Windows 7, Windows 10, on a physical computer, and in VirtualBox. With built-in Windows defender, with other antivirus (not listed above). Only in the 32-bit version (program). Tested only on 64-bit version of Windows.
I was also able to reproduce the error. Rarely, after a series of operations (in the program), and closing, performed quickly and on the keyboard.Could you elaborate as to the sequence?
For now I have discovered something promising.Why do you do this? This is not needed. All these controls were created with an "Owner" (the form), and the owner takes care of destroying them. Normally it works correctly, but beginning to destroy components yourself at the moment when the form is about to do the same sounds like calling for trouble. Normally, the main form normally does not need an OnClose handler at all.
procedure TAppForm.FormClose(Sender: TObject; var CloseAction: TCloseAction); //begin //CloseAction:= caFree; var i: Integer; C: TComponent; begin for i := ComponentCount - 1 downto 0 do begin C := Components[i]; if C is TCustomForm then begin //writeln('Component[',i,'] is Form: ',C.ClassName,':',C.Name); FreeAndNil(C); end; end; end;
Why do you do this? This is not needed. All these controls were created with an "Owner" (the form), and the owner takes care of destroying them. Normally it works correctly, but beginning to destroy components yourself at the moment when the form is about to do the same sounds like calling for trouble. Normally, the main form normally does not need an OnClose handler at all.Yeah, that's what I also already said. And what's even more... It really doesn't do anything because none of the components which are owned, are TCustomForm. So this code really doesn't do anything. It just confused the whole issue and code.
It almost looks as if the 32-bit compiler of fpc 3.0.4 has an issue.But you say Laz 1.8.4 64 bit also gives an error or is that a type/switch?
Right. Seems that I missed this one. This brings the compiler out of focus - which agrees with my experience that almost 100% of the bugs are caused by user code, not by the compiler.It almost looks as if the 32-bit compiler of fpc 3.0.4 has an issue.But you say Laz 1.8.4 64 bit also gives an error or is that a type/switch?
So it's the assigning of Left/Top etc to the Form itself.Ah! Writing "Left := Left + 1" already produces the error, forget about the MulDiv crap that I wrote...
Putting an exit; right after the with Control etc. confirms that.
Putting an exit before the with Control, the error stays away.
Now I reloaded the original project, unchecked the heaptrc, commented the ScaleDPI call -> bug is back. Frustrating...Not for me.
Can you post a simple non-lcl demo to demonstate the issue to the compiler people?
- Laz trunk / fpc 3.0.4 (32 bit) --> ERRORWith the original in combination with trunk you also didn't get the error.
- Laz trunk / fpc trunk (32 bit) ---> NO ERROR
Might be related. Not sure.
From the logs. Fixed in 3.1.1.
Revision: 34687
Author: michael
Date: zondag 9 oktober 2016 10:16:15
Message:
* Fix bug 30701 (https://bugs.freepascal.org/view.php?id=30701): allow formatting arguments in str() and writeln()
----
Modified : /trunk/packages/fcl-passrc/src/pastree.pp
Modified : /trunk/packages/fcl-passrc/src/pparser.pp
Modified : /trunk/packages/fcl-passrc/tests/tcstatements.pas
Modified : /trunk/packages/fcl-passrc/tests/tctypeparser.pas
So using "string[255]" is actually an array of sorts, and is assigned a safe domain.Yes, I found that using array[0..1000] of char instead of string also fixed the problem.
Project CmdRPN raised exception class 'External: SIGSEGV'.
In file '..\inc\heap.inc' at line 518:
remove_from_list_fixed(pmc, fixedlist);
#0 REMOVE_FREED_FIXED_CHUNKS(0x28a90f0) at ..\inc\heap.inc:518 #1 FREE_OSCHUNK(0x2898b82, 0x28a90f0) at ..\inc\heap.inc:527 #2 APPEND_TO_OSLIST(0x28a90f0) at ..\inc\heap.inc:556 #3 SYSFREEMEM_FIXED(0x2898b82, 0x28a95cc) at ..\inc\heap.inc:1116 #4 SYSFREEMEM(0x28a95d0) at ..\inc\heap.inc:1177 #5 fpc_freemem(0x28a95d0) at ..\inc\heap.inc:368 #6 fpc_ansistr_decr_ref(0x19fc021) at ..\i386\i386.inc:1455 #7 WIDEINITS_$WIN32WSEXTDLGS at :0 #8 fpc_finalize(0x558658, 0x5723c0) at ..\inc\rtti.inc:182 #9 ARRAYRTTI(0x558640, 0x57d064, {procedure (POINTER, POINTER)} 0x266fdc0) at ..\inc\rtti.inc:144 #10 fpc_finalize(0x558640, 0x57d054) at ..\inc\rtti.inc:193 #11 RECORDRTTI(0x5585a0, 0x57d0e1, {procedure (POINTER, POINTER)} 0x266fdf4) at ..\inc\rtti.inc:112 #12 fpc_finalize(0x5585a0, 0x57d078) at ..\inc\rtti.inc:198 #13 SYSUTILS_$$_finalize$ at :0 #14 FINALIZEUNITS at ..\inc\system.inc:922 #15 INTERNALEXIT at ..\inc\system.inc:998 #16 DO_EXIT at ..\inc\system.inc:1041 #17 main at CmdRPN.lpr:59 |
and that its thread can be randomly overwritten. That process can also clear out its garbage by a subsequent write that is luckily the same or greater size and has compatible data.
Probably not related, but the "if TmpStr <> RegBox1.Text" in OnChange somehow triggers another OnChange, why's that?That's also what I saw with "if Edit1.Text <> 'a' then ". It triggered the crash ending the program.
The above sequence triggers 3 onchanges.
If I comment out the "if TmpStr <> RegBox1.Text" I only get 2 OnChanges
Can FloatToStrF have the same issue as Str() has?I think so, it uses Str() with decimals internally. I have not seen them in the Format() function which does use str() but without the decimals parameter.
I have already made TmpStr a local variable, and implemented the Str() to lshortstring as someone has suggested. It has been operating without fail ever since.Like I said, if you used {$H-} you wouldn't need to use ShortString because all Strings are automatically ShortStrings (i.e. String[255]). So that is the safest way. You wouldn't need to adjust anything else and your program will be safe for the future too.
But in UpdDsp and UpdSto there are multiple writes to TmpStr. I don't see how it can be protected within the function block. It should be just as vulnerable with that situation.Moving TmpStr to local (as LongString), you eliminate a lot of reference counting and using it (directly) in Str() wouldn't impact it as much. But with a lot of Str() with LongString, it could still go wrong (probably). But the chances of it happening are a lot less.
Just add {$H-} at the top (instead of {$H+} and be done with all the hassle of checking for Long- and ShortStrings altogether.This recommendation is probably ok for a calculator application, but not in general, IMHO. The user at least must be aware of the consequence that strings cannot be longer than 255 characters then.
Yes, that's wat I also already mentioned in a previous post. Because the application isn't really string oriented (as calculator) the {$H-} would be the safest and fastest option. For all others you need to make certain choices. So when dealing with FPC 3.0.4 and lower in combination with Str() in {$H+} you need to be careful.Just add {$H-} at the top (instead of {$H+} and be done with all the hassle of checking for Long- and ShortStrings altogether.This recommendation is probably ok for a calculator application, but not in general, IMHO. The user at least must be aware of the consequence that strings cannot be longer than 255 characters then.