Is it me or is there something wrong with the 64bit windows Designer?

[jamie]

It seems I've detected an issue that may have been there for some time that I just didn't notice.

Lately I mostly code using the 32-bit Laz and I don't ever have issues with it.

But for the 64 bit version, this just started happening or I just didn't notice it.

For example.
 I have FPSpreadSheet installed

If I drop a TsWorkBookTabControl on the form and then use the Delete key to remove it, it may work the first time, or it just does not delete and after that it just gets worst. or I can't move it but then the IDE locks up when trying to delete it.

 And it seems this is related to many controls that use the tabsheet as a building block.

 There are a couple of others but that's a starter.

 I have 4.6 installed so I went back to 4.2 (64), that has basically the same issues, and this is on 3 different computers.

  But I did find version 4.4 on the computer that I keep the Trunk updated on, for which I had an install there, that one seems to work ?

  I even tried the 64 bit version with the 3.2.4RC and that has the same issue. I am not having any issues with other software on my PC; I ran a memory scan which took a while and that came up empty.

The working 4.4 Version has all of the same controls install as does on the trunk because they are on the same PC, the 4.4 works ok from what I can see.

 Any ideas?

Jamie



 

[Martin_fr]

Check for any errors shown in the "messages" window.

Also if you can run from/with console (or otherwise with --debug-log=file) check the console/log for errors.

[jamie]

Ok, I just updated the trunk with today's work.

Dropped a Notbook something on the for from the LazControls and it dropped ok and I was able to move it around but deleting shows the resullts, then the IDE will be in a semi lock state and a dialog with a Double "Access Violation" appears when I tried to close the IDE.

Image attached.

[jamie]

I just realized that even the 32-bit version of 4.6 was also doing this, now that puts me in a stuck place because that is where I've been living lately.

 So, I found then 4.4-32 from the net, installed it, tested first before rebuilding with extra components, it was good, then rebuilt for extra components, still good.

 So here we stand, either we have a memory overwrite somewhere that isn't showing in
4.4 or something got change in 4.2 that I didn't notice, then works in 4.4, now back to what 4.2 does on my end using 4.6.

 So, I'll keep testing with trunk, because all I need to do is drop a TTabCOntrol on the form, wait for it to render and then delete it and watch the show.

Jamie

[wp]

Confirming this observations with Laz/main, any controls descending from TCustomTabControl seem to be affected, 32-bit or 64-bit does not matter. I am on Windows 11 - no idea whether other widgetsets have the same issue.

Quick test: Drop a TTabControl on a form, delete the TTabControl by pressing the DEL key --> The IDE does not respond, after a while a message saying that an exception has occurred when the tabcontrol was deleted, an "Access violation" is reported later when the IDE is closed.

Stack trace:

Code: [Select]

Stack trace:
  $00000000
  $0056E2EA  TWINCONTROL__DESTROYHANDLE,  line 5447 of ./include/wincontrol.inc
  $005AE767  TTABCONTROL__DESTROYHANDLE,  line 633 of ./include/tabcontrol.inc
  $0057055E  TWINCONTROL__DESTROY,  line 6722 of ./include/wincontrol.inc
  $005A91B8  TCUSTOMTABCONTROL__DESTROY,  line 339 of ./include/customnotebook.inc
  $005AEF86  TTABCONTROL__DESTROY,  line 811 of ./include/tabcontrol.inc
  $004103F2
  $008E4ACC  TCUSTOMFORMEDITOR__DELETECOMPONENT,  line 652 of customformeditor.pp
  $008DF10E  TDESIGNER__DODELETEPERSISTENT,  line 3053 of C:/Lazarus/lazarus-main_fpc3.2.2/designer/designer.pp
  $008DF785  TDESIGNER__REMOVEPERSISTENTANDCHILDREN,  line 3196 of C:/Lazarus/lazarus-main_fpc3.2.2/designer/designer.pp
  $008DEE77  TDESIGNER__DODELETESELECTEDPERSISTENTS,  line 2998 of C:/Lazarus/lazarus-main_fpc3.2.2/designer/designer.pp
  $008DE68C  TDESIGNER__KEYDOWN,  line 2850 of C:/Lazarus/lazarus-main_fpc3.2.2/designer/designer.pp
  $008DF34E  TDESIGNER__ISDESIGNMSG,  line 3089 of C:/Lazarus/lazarus-main_fpc3.2.2/designer/designer.pp
  $005785EA  TCONTROL__WNDPROC,  line 2248 of ./include/control.inc
  $0056E61B  TWINCONTROL__WNDPROC,  line 5547 of ./include/wincontrol.inc
  $00439A6F  TCUSTOMFORM__WNDPROC,  line 1443 of ./include/customform.inc
  $0063656A  DELIVERMESSAGE,  line 114 of lclmessageglue.pas
The crash can also be followed at runtime (i.e., there is no need to debug the IDE...): Write a project, drop a TTabControl, drop a button, and add this OnClick handler:

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. begin
3.   TabControl1.Free;
4. end;  

Click on the button and you will get an error message "Access violation reading from address $BAADF00D." - BAADFOOD = some memory issue...
Adding a custom option "-gw3" to "Additions and overrides" allows to debug into the LCL unit.

(Too late here to persue this issue at the moment...)

[Martin_fr]

Fixed https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/4fadf2a2ccc589d618df2c9668adbd6c20ca48ec

It doesn't crash if you create/destroy the form (i.e. run/close an app with TTabControl), only if you destroy the TTabControl while the form is kept. So it evaded detection in testing.

I have 4.6 installed so I went back to 4.2 (64), that has basically the same issues, and this is on 3 different computers.

  But I did find version 4.4 on the computer that I keep the Trunk updated on, for which I had an install there, that one seems to work ?

I don't know what failed in 4.2, but it wasn't the same issue. This issue was new to 4.6.

any controls descending from TCustomTabControl seem to be affected,

I only found TTabControl (and its descendents). TCustomPageControl does not have the FCanvas.
TPageControl also does not crash for me.

[wp]

Fixed https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/4fadf2a2ccc589d618df2c9668adbd6c20ca48ec

Thanks

any controls descending from TCustomTabControl seem to be affected,

I only found TTabControl (and its descendents). TCustomPageControl does not have the FCanvas.
TPageControl also does not crash for me.

I should have checked inheritance before writing this: Besides TTabControl, also TExtendedTabControl and TsWorkbookTabControl (in FPSpreadsheet) were crashing, but they inherit from TTabControl, too. All of them are fixed now.

[jamie]

I I believe the icon bar with the components is also composed of a tab control and may also resolve an issue I had recently which I will retry again thank you.

 The behavior of the fault was the same when droppi g and removing the control.

I) need to make rhe changes manually.
From my phone.
Jamie

[mossbruc]

Please, please help.

I have a substantial project that is now affected by this. Use Lazarus 4.6,fpc 3.2.2 on Windows 10, 64 bit version.
I added a TTabcontrol and I now cannot delete it anymore. Project cannot be compiled nor saved.
How do I install this new commit? Is there a new installer?

Cheers

Joerg

[wp]

I added a TTabcontrol and I now cannot delete it anymore. Project cannot be compiled nor saved.
How do I install this new commit? Is there a new installer?

Martin's fix is in the trunk and fixes versions of Lazarus, it will not be ported back to any release. But you can patch your version by yourself. It's easy, the change is only a single line:

• Make a backup copy of the file "tabcontrol.inc"; it is in folder "lcl/include" of your Lazarus installation.
• Open this file in the IDE
• Find the implementation of the destructor TTabControl.Destroy.
• Replace the line "FCanvas.Free;" by "FreeAndNil(FCanvas);"
• Save and rebuild the IDE ("Tools" > "Build Lazarus with profile").
• When the IDE restarts after a while you will be able to delete a TabControl without any more issues.

[mossbruc]

Thank you, thank you, thank you, this worked.
You saved a considerable amount of work!

Joerg

[jamie]

I am still curious as to how that happened in the first place?

Using FreeAndNil implies that the TAbControl is still getting accessed after it has been freed ?

Jamie

[Martin_fr]

I am still curious as to how that happened in the first place?

Using FreeAndNil implies that the TAbControl is still getting accessed after it has been freed ?

Not the tabcontrol, but the internal canvas. Also, not after, but during (while still in calls from the destructor)

The internal canvas was previously leaking (not memory, but a handle object from windows). That got fixed. And it "seemed" to work fine.

All the apps with tab-controls worked. Because if you destroy the owning form, and if that destroys the tab-control, then the order of freeing stuff is different.
It is also works , if the tabcontrol is destroyed on its own, but not visible (doesn't have a handle).
Only if you destroy the tabcontrol while it has a handle, then it crashes. And therefore the crash did not happen in testing.

The handle-leak (not sure if the one on the tabcontrol, there were several... one of them was reported) had caused crashes on Linux.

[jamie]

I must be misunderstanding something because I can't see how nilling an object prevents leaks of resource handles.

  That would imply that the cache list is directly linked to where handles were used kind of a backwards method.

Jamie

[Martin_fr]

nilling the object did not prevent the leak. That was done in the fix for the leak.

But the release of the handle (unexpectedly) can be called after freeing the object (in which case the handle has been released already). nil can prevent releasing the no longer existing handle on a freed object. (in DestroyWnd, IIRC)


That is DestroyWnd (IIRC, that is the name, something alike) can be called either before, or after the line that destroys FCanvas.