Hi Bruno & Pieter,
I believe I've found a bug in TAdvCheckedTreeView (or possible FastMM5). Here's a video that explains the problem:
https://www.loom.com/share/d233de3e07a1468492de0ac03f7e8e43
I've uploaded the example project FastMM5-Bug.zip (9.5 KB)
Originally, as you can see from the video, I thought this was a FastMM5 bug. I sent it to Pierre to take a look. He seems to think it's not a problem with FastMM5. Here's his response:
Hi Steve,
I hope you are well!
I downloaded the trial from their website and ran the test application using FastMM version 4 in FullDebugMode and I also got the crash. The error reported was a read at address $808080xx which is the telltale sign that an object or memory block that was previously freed is still being used.
Version 4 has been stable for more than a decade, and version 5 is a complete rewrite so it is extremely unlikely that both would have bugs that only manifest themselves in that component. Also, the memory manager is generally very heavily used, so is unlikely for a crash bug in the core routines (getmem, freemem, reallocmem) to survive in the wild for very long - especially a bug that can be triggered in single-threaded code.
I therefore conclude that it is a bug in the component that just happens (through pure chance) to not display any obvious symptoms when using the default memory manager (which is a scaled down FastMM v4).
Unfortunately the TMS trial does not include the source code so it is hard for me to investigate further. If TMS does not object, you're welcome to send me the source and I will try to find the bug. I will delete the source afterwards.
Best regards,
Pierre
I'd appreciate it if you'd take a look.
Many thanks,
Steve
Hi,
Unfortunately we not have FastMM5 installed here. Is there a crash log generated when using FastMM5? It could potentially be due to the destroy mechanism of the edit, but it's strange that this doesn't happen without FastMM5
Hi Pieter,
You can download it from here:
https://github.com/pleriche/FastMM5
Apparently, according to Pierre, the same error occurs using FastMM4.
Steve
Hi, thanks for the link. I have been able to reproduce the issue, but really cannot think of a reason why FastMM would create an access violation. The edit is properly being destroyed when clicking on the Enter key, in the keyup routine. Removing the line FInplaceEditor.Free fixes the issue but will introduce memory leaks, so the line is essential.
{$IFNDEF FMXMOBILE}
while FInplaceEditorTimer.Enabled do
Application.ProcessMessages;
{$ENDIF}
{$ENDIF}
{$IFDEF CMNWEBLIB}
// FInplaceEditor.Free;
{$ENDIF}
Thanks Pieter,
I've done a test using FastMM4 (although not in full debug mode) and that didn't give an AV. So the bug may well be with FastMM5. Is there any way you can provide access to the source code for Pierre to debug? He says he'll delete as soon as the bug is found.
It looks like you're destroying the editor object using a Windows message. I've never come across this before and I suspect this is may have something to do with the error (possibly on the FastMM5 side).
Best regards,
Steve
You can ignore the first code, it's not executed. Only this line
FInplaceEditor.Free;
Is the one that is executed on VCL. The Application.ProcessMessages is not executed on VCL.
Hi Pieter,
Here's a suggestion from Pierre:
A suggestion you can perhaps make to the author is to set FInplaceEditor := nil everywhere it is freed. This way it should immediately cause an A/V if it is used after being freed, and it should then be more obvious where the real problem lies.
I hope this helps.
Steve
Hi, this is already being done.
c := True;
DoCloseInplaceEditor(FUpdateNode, FUpdateNodeColumn, FInplaceEditor, ACancel, c);
if c then
begin
b := True;
DoBeforeUpdateNode(FUpdateNode, FUpdateNodeColumn, n, b);
if b and not ACancel then
begin
UpdateCount := UpdateCount + 1;
if Assigned(FUpdateNode.Node) then
FUpdateNode.Node.Text[FUpdateNodeColumn] := n;
DoUpdateNodeText(FUpdateNode, FUpdateNodeColumn, n);
UpdateCount := UpdateCount - 1;
DoAfterUpdateNode(FUpdateNode, FUpdateNodeColumn);
DoNodeChanged(FUpdateNode);
end;
FInplaceEditor.Parent := nil;
{$IFDEF FMXLIB}
FInplaceEditorTimer.Enabled := True;
{$IFNDEF FMXMOBILE}
while FInplaceEditorTimer.Enabled do
Application.ProcessMessages;
{$ENDIF}
{$ENDIF}
{$IFDEF CMNWEBLIB}
FInplaceEditor.Free;
{$ENDIF}
FInplaceEditor := nil;
FInplaceEditorActive := False;
end;
Hi Pieter,
Can I come back to Pierre's offer to debug using the source. Is it possible to provide Pierre with access to the source code for the sole purpose of debugging this issue?
Thanks,
Steve
Yes, If you have the source code, you can give him access to debug what exactly is going on, no problem. We could debug it here ourselves, but have no insight on how FastMM is actually working.
We have looked at the implementation of the fix and applied it here. The next version will address this
Brilliant! Thanks for this and for your flexibility with the source code.
Steve
Your welcome. I removed the post with the source code for security/licensing purposes. ;-)