Recent

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

nanobit

  • Full Member
  • ***
  • Posts: 160
Re: Windows 10 and FormClose
« Reply #75 on: July 10, 2019, 10:13:47 pm »
I made a quick test, but I have no fpc debug version.
str(f:w:d, s) creates severe memory corruptions, in fpc 3.0.4 and fpc 3.2.
I tested with f := 0.001 (and others), (w = 0..7), (d = 3), all combinations buggy. The effect:
Crashes later at different places in apps: at other (unrelated) string expressions in other routines.
The more string expressions in the app, the more likely a crash (at a string expression).
str() is using fpc_ansistr_float. It's a huge bug.

Typical errors: SIGSEGV, SIGILL (not SIGKILL), ERangeError (by fpc_ansistr_rangecheck)
Heaptrc memory manager has no impact:
Is either used or unused (if environmentvar: HEAPTRC = "disabled")

Update: Cannot reproduce crash with current FPC trunk:
I use same project setting, same Lazarus 2.0.2 (but rebuilt with FPC trunk), and project shows no crash. Don't know the reason, maybe it's solved or not.
With FPC trunk, the rvk example behaves different too: no crash.

Last update:
Since a day I cannot reproduce my reported crash.
My current assumption is: This was the sideeffect of an invalid breakpoint.
Which means, we have no different test project now.
« Last Edit: July 12, 2019, 09:55:02 am by nanobit »

wp

  • Hero Member
  • *****
  • Posts: 11856
Re: Windows 10 and FormClose
« Reply #76 on: July 10, 2019, 11:42:08 pm »
Can you post a simple non-lcl demo to demonstate the issue to the compiler people?

nanobit

  • Full Member
  • ***
  • Posts: 160
Re: Windows 10 and FormClose
« Reply #77 on: July 11, 2019, 08:56:59 am »
Can you post a simple non-lcl demo to demonstate the issue to the compiler people?

Such test project is probably not possible within days, because in the exe file,
every compiled line before str() has impact on the occurrence of crash
and I cannot publish my source. On every source change (exclude any unit,
or any sourceline) the crash effect changes (mostly disappears).

But I know for sure, the bug is not LCL: The normal LCL unit files are initialized
in uses clause, but nothing else of LCL is called before the crash, my project unit is:

begin
  someUnit.doCrashTest; // crashes occur here (after calling str(f:w:d, s) in there)
  exit; // always exit here

  // unused, but can't be removed (changes exe file, thus removes crash above)
  Application.Scaled:=True;
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;   
end;

rvk

  • Hero Member
  • *****
  • Posts: 6111
Re: Windows 10 and FormClose
« Reply #78 on: July 11, 2019, 09:12:07 am »
Yes, it's the same with removing the empty if statement in my last clean example. The code shouldn't do anything but removing or changing it makes the crash go away.

wp

  • Hero Member
  • *****
  • Posts: 11856
Re: Windows 10 and FormClose
« Reply #79 on: July 11, 2019, 09:46:54 am »
Then somebody (rvk?) should use rvk's demo in a bug report, better than nothing and perfectly reproducible.

But we should be sure that the bug has not yet been fixed in the meantime. When I compile and run rvk's demo with FPC trunk the crash does not appear any more. Regarding the complexity of the issue, this does not mean much, I know, but nanobit, can you confirm the same with your own test program(s)?

rvk

  • Hero Member
  • *****
  • Posts: 6111
Re: Windows 10 and FormClose
« Reply #80 on: July 11, 2019, 10:12:14 am »
- Laz trunk / fpc 3.0.4 (32 bit) --> ERROR
- Laz trunk / fpc trunk (32 bit)  ---> NO ERROR
With the original in combination with trunk you also didn't get the error.

Later this morning, I will also refresh my trunk installation and try it with fpc trunk 32bit.

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: Windows 10 and FormClose
« Reply #81 on: July 11, 2019, 10:57:33 am »
If you cannot get it to crash in a plain fpc program, it's very unlikely that some fpc devel will investigate this.
I wrote a simple string manipulating program that does 400000 string operations including calls to procedures with a string as parameter (var, value, const, constref) and 80000 calls to str(). It refuses to crash.
Heaptrace also does not barf on it.

This is with fpc 3.0.4 and fpc trunk.

Bart
« Last Edit: July 11, 2019, 11:15:41 am by Bart »

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: Windows 10 and FormClose
« Reply #82 on: July 11, 2019, 11:14:58 am »
I cannot get rvk's clean example (#72) to crash.

Lazarus 2.1.0 r61175 FPC 3.0.4 i386-win32-win32/win64, tested 64 and 32 bit
Lazarus 2.1.0 r61564 FPC 3.3.1 i386-win32-win32/win64, tested 64 and 32 bit (fpc trunk r42348)

Bart
« Last Edit: July 11, 2019, 11:57:28 am by Bart »

wp

  • Hero Member
  • *****
  • Posts: 11856
Re: Windows 10 and FormClose
« Reply #83 on: July 11, 2019, 11:31:55 am »
For me, both examples of replay #71 as well as the clean example of reply #72 crash with Lazarus 2.1.0 r61542M FPC 3.0.4 i386-win32-win32/win64.

They do not crash with Lazarus 2.1.0 r61564M FPC 3.3.1 i386-win32-win32/win64 r42348

[EDIT]
Seeing the different Laz trunk svn versions I updated my standard trunk installation (-->Lazarus 2.1.0 r61564M FPC 3.0.4 i386-win32-win32/win64). Now the example #2 no longer produces the error, but example #1 still does as well as the "clean" example.

Considering the dependence of this bug on numerous unknown parameters I fear it will not be possible to verify that a fix is successful...
« Last Edit: July 11, 2019, 02:52:18 pm by wp »

rvk

  • Hero Member
  • *****
  • Posts: 6111
Re: Windows 10 and FormClose
« Reply #84 on: July 11, 2019, 12:10:51 pm »
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: 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

Cyrax

  • Hero Member
  • *****
  • Posts: 836
Re: Windows 10 and FormClose
« Reply #85 on: July 11, 2019, 12:26:35 pm »
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: 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

No, that fix is only for pascal parser and pas2js which uses it to transpile pascal to javascript. Compiler uses own parser.

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Windows 10 and FormClose
« Reply #86 on: July 11, 2019, 12:28:13 pm »
Just an observation...

It seems evident to me that a dynamic string isn't protected by a fixed allocation, 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.

That is why a global string of unfixed or random length becomes problematic. Likewise, a global integer, real, double, or an array do not pose problems ... they have fixed allocations. So using "string[255]" is actually an array of sorts, and is assigned a safe domain.
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 #87 on: July 11, 2019, 12:33:41 pm »
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.
Using old string[255] should also work because that's a array[0..255] of char.

So, my initial thought was also that the characters where written outside of the reserved area of the string.

(You can also use ShortString.  ShortString = String[255]; )

Also... ShortString (and String[255]) shouldn't be reference counted.
But I can't imagine Str() doesn't handle the reference counter correctly.

Setting {$H-} instead of {$H+} at the top would fix it too because all strings would become shortstrings.
« Last Edit: July 11, 2019, 12:38:15 pm by rvk »

metis

  • Sr. Member
  • ****
  • Posts: 300
Re: Windows 10 and FormClose
« Reply #88 on: July 11, 2019, 02:02:42 pm »
@rick2691

I tried Your 'Laz-CmdRPN - Copy.zip' (with HeapTrc disabled) and entered, e.g.:
(Sorry Guys: This ZIP was already posted at Page #3: https://forum.lazarus.freepascal.org/index.php/topic,45872.msg325980.html#msg325980, but
 I got no Internet at Home and You marched on a lot since I accessed Internet the last Time.)

  <22> -> <Enter> -> <55> -> <+> -> Close: no Error

  <22> -> <Enter> -> <55> -> Close: no Error

  <2> -> <Enter> -> <5> -> <+> -> Close: no Error

  <2> -> <Enter> -> <5> -> Close: ERROR (see attached 'ErrorOnClose.jpg')

No matter, if the above Sequence was typed or clicked.

Then I tried <123> -> <Enter> -> <456> -> <+> -> Close:
if clicked, there is no Error, but if typed the same ERROR as above is raised.

All of this no matter, if the App was closed with the Titlebar's [X] or via <Alt+F4>.

That's, what You described here: https://forum.lazarus.freepascal.org/index.php/topic,45872.msg326236.html#msg326236
(You wrote "$0040F338", but maybe it's a TypeError.)

Now, here comes the News:
I tried it out with my WinXP 32bit SP3 + Microsoft .NET Framework 4 (Lazarus v1.8.4 + FPC v3.0.4).
-> Proven, that these Errors are not due to resp. restricted to Win10.
« Last Edit: July 16, 2019, 04:38:18 pm by metis »
Life could be so easy, if there weren't those f*** Details.
My FFmpeg4Lazarus = FFPlay4Laz + FFGrab4Laz + FFInfo4Laz

BrunoK

  • Sr. Member
  • ****
  • Posts: 452
  • Retired programmer
Re: Windows 10 and FormClose
« Reply #89 on: July 11, 2019, 03:20:04 pm »
Win 10 32 bit with CmdRPN2.zip test.

Entry : <1> <Enter> <Alt-F4>

Results in
Quote
Project CmdRPN raised exception class 'External: SIGSEGV'.

 In file '..\inc\heap.inc' at line 518:
remove_from_list_fixed(pmc, fixedlist);

Call stack :
#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

It does not happen using heaptrc, cmem and cmem with heaptrc (experimental) but those allocate memory in different chunk sizes.

Punctually adding for example :
Code: Pascal  [Select][+][-]
  1. procedure TAppForm.RegBox1Change(Sender: TObject);
  2. var
  3.   lTmpStr : string;
  4. begin
  5.   lTmpStr := TmpStr;
  6. etc..
  7.  
also  seems to hide (?) the bug. All I can think about it is that lTmpStr := TmpStr does modify the reference count of TmpStr.

What seems to be causing trouble is the use of ansistring.
From what I could trace, the strings have sufficient memory for the Str(Reg1: 0: Dsp, TmpStr); procedure which uses internally a shortstring. At every stage in the trace the ansisstring buffers seem to getmem sufficient memory to hold the intermediate ansistrings.

So a spurious update of an ansistring (maybe in a freed bloc because the part of Str() function that deals with copying the shortstring buffer to the result does many memory operations) must write something in the heap memory to damage the heap management, maybe such as writing to a previously FreeMem'd location and crashing the chain of available chunks.

Problem seems to be the reference counting of ansistring and all the freemem / getmem involved.

What would be interesting is if someone manages to setup a program that shows the discussed problem before exiting the program.

 

TinyPortal © 2005-2018