Sue King

I have just upgraded from Delphi 10.3 to 10.4. I have been using FastMM 4.992 in my projects. The main form has an initialization ReportMemoryLeaksOnShutdown := True; TfrmMain.SetMyStyle; SetMyStyle is defined class procedure TfrmMain.SetMyStyle; var sStyleFile: string; bOK: Boolean; sPath: string; begin sStyleFile := 'C:\DevFolder\21.0\bin\Win32\Debug\Styles\Calypso_Win.style'; if TFile.Exists(sStyleFile) then begin bOK := TStyleManager.SetStyleFromFile(sStyleFile); end; end; In 10.3 this works without any issues. In 10.4, FastMM4 generates an AV on closedown FastMM has detected an attempt to call a virtual method on a freed object. An access violation will now be raised in order to abort the current operation. Unfortunately the block header has been corrupted so no history is available. The current thread ID is 0x27F4 and the stack trace (return addresses) leading to this error is: 6DCB67 {FMX.Controls.pas][FMX.Conrols.TControl.Repaint][3547] 76A260 FMX.Styles.Objects.pas][FMX.Styles.Objects][Styles.OBjects.TButtonStyleObject.NormalTriggered][2357] .... I have GExperts install, and it generats a message Project xx.exe raised exception EAccessVioloation with message 'Access Violation at address 776B4662. Read of address 00000000'. This is in a new project, which has no components on the form. The only changes to the default new project are the uses in the dpr for FastMM, the class procedure, initialization and addition uses in the main form for FMX.Styles and System.IOUtils. The options I have changed in FastMM4Options.inc are {$define NeverUninstall} {$define UseRuntimePackages} {$define NoDebugInfo} {$define FullDebugMode} {$define CatchUseOfFreedInterfaces} {$define ClearLogFileOnStartup} {$define DisableLoggingOfMemoryDumps} {$define HideMemoryLeakHintMessage} The style I am using is Calypso_Win.style. This is one of the premium styles available through Getit. Does anyone have any idea of where I should be looking for the problem. Sue

Thanks again. I had a look at the Bitmap Style Designer and can see that I can use it to make adjustments to the style I have chosen. There are some button borders that are too bright so I should be able to adjust them here. My original problem remains. One of the objects in the style causes an AV on closedown if FullDebugMode is on using FastMM4 4.992, not the version shipped with Delphi. Looking at the object in the Designer doesn't give me any clues as to what is going wrong. The issue happens with other premium styles. Standard styles are OK. I can get around the issue by using a modified style with the problem object removed, when testing and debugging, and using the full style for release. I did not have any problems with the style in 10.3. It is only since upgrading to 10.4, so something has changed in FMX. I will probably lodge a bug report, but doubt anything will happen in the short term, if at all, as it occurs when you don't use the built in FastMM. I have learnt a lot about styles, which is something I wanted to do, and feel I have a much better understanding of how it all works now. Thanks again for your guidance.

Thank you for pointing this out. I will see what I can do with it tomorrow. Maybe comparing styles that have the problem and those that don't will help me resolve the issue.

For anyone who has this issue, it relates to the windowborderstyle in the .style file. If the client object is deleted there is no AV on closedown. Another work around is to set Border-> Styling = False for the form. It does look odd though. So now to find out how to change the colour of the window border without this element, or create a similar element that doesn't have the issue.

The issue is the use of Premium styles. Standard styles do not cause an error.

I use Go to Line Number but not the drop down.

Delphi Rio Update 1, Win x64, 32 bit FMX application I am currently working with a third party component library. When I use one of the components, FastMM4 (4.991) is reporting an interface being used after being freed as the app closes down. When contacted, the supplier of the product responded that there had not been any other reports of this happening, and perhaps it was a false positive. The suggestion is to use the default memory manager, as this doesn't show any errors. I have been using FastMM4 for years, and have never had an issue before. However my code isn't nearly as complex as that in the component in question. I can avoid the error being reported by turning off CatchUseOfFreedInterfaces. Unfortunately I then get an AV with memory accessed at $80808080 and heaps of other memory leak errors that makes debugging very slow as every time the program exits I have to wait for the memory leak report, which I need to check my own code. At the moment, I feel I need to avoid using the component. Is a false positive a likely scenario ? Do other people get false positives when using FastMM4 ? TIA, Sue

Thank you for your responses.

The component vendor has investigated the code and believes this is a false positive. They are interested in making contact with someone working on FastMM to try to resolve it. Who should I suggest ? TIA

I just upgraded to 1.3.13.79. I have no delay in loading 10.3.2, and no crash on exit. Editor enhancements are not disabled. GExperts has its own menu in the IDE (not part of tools). I used the batch command to install it specifically for Rio. Not sure what might be different. I haven't used the IDE much. If I get a different result later in the day I will report back. Sue

kbmMemTable has a good CSV import unit for importing into their memory table. I use this and then process the data from there. It isn't an import component as such but part of the table. It can be used in both VCL and FMX.

Mileage has a wider use than just a measure of miles. For example, it is not uncommon to hear a phrase such as 'We had good mileage from that' where that can refer to clothes, appliances, tools or something that get used.

Possibly, although the assurance that it isn't a false positive maybe have been the deciding factor.

Thank you all for your responses. The vendor is looking into this.

@Sherlock The message I sent to the vendor described a very simple example that showed the error. I have referenced this forum for them to see responses to my inquiries, so hopefully they will see @David Heffernan 's response and have another look into it.

You could compile to the source/development directory and use Build Events after compile to copy it to the Applications folder for testing.

R124 does not show the problem in the test application. All versions until R47 do show the problem. R47 does not. I have been able to get R115 working by commenting out HookLoadResString.Enable. In earlier versions that didn't work, there were different changes I made that 'fixed' the error. It seems to me that under most conditions the error doesn't show, but when it does, its symptoms are unpredictable. The test that @dummzeuch created generating exceptions in a multithreaded application (which is what is happening in the demo) did not create the right conditions to show the error. The nexus code is very much more complex. @mael The test program is one of the example projects provided by Nexus. It is in Examples->Delphi->Remoting->Client to Client Messaging. I have simply added gnugettext.pas to the project. To generate the problem, Click on Connect and then Disconnect. The program stops responding and has to be killed as it generates a never ending loop trying to close sockets used for messaging. I think you should be able to recompile this example with the trial dcus. I've posted nexus to confirm this but haven't had a response yet.

I have found a possible solution to this. In TGnuGettextInstance.dgettext I replaced UTF8Decode with UTF8ToUnicodeString Is there any reason why UTF8ToUnicodeString could not be used instead of UTF8Decode ? As far as I can see the difference is that UTF8Decode returns a widestring, and UTF8ToUnicodeString returns a UnicodeString, which is what the result field is defined as. Does this mean there is an extra conversion from WideString to UnicodeString that might be causing the issue ?

This test does not show the problem. I was about to try something multi threaded myself, so I'm using your test as a base and looking at the code that does fail to try and make your test more like the failing test. This is giving me more insight into the code that is actually failing so I will try again to catch the exception that shows in the call stack. In the test I'm running, I am not calling any of the gnugettext functions directly, like AddDomain. It is a Nexus demo with gnugettext.pas added to the dpr. All calls to gnugettext are done indirectly using LoadResString (as far as I can see). There are also no .mo files for translating. Nexus hooks into the exception handler and has its own processing of exceptions before they are raised. Early versions of gnugettext did not cause issues. I did do some investigating to see when the problem was introduced, which I think I mentioned in an earlier post. I took another approach to see if it is related to the processor - trying it on another machine that has an Intel processor, not an AMD. It still goes into a loop, so that rules that idea out.

I don't think that the IDEFixPack has anything to do with gnugettext translations. I was wondering if the bug found in IDEFixPack might also be in some assembler called somewhere by something in gnugettext. It was a long shot as the bug is related to converting utf8 strings.

This might be completely off beam, but I thought it worth raising. There was a problem in IDEFixPack with some older AMD processors which involves converting UTF8 strings. Quoting from the thread about this issue : << This fixes the usage of a SSE 4.1 CPU instruction ("ptest") in a code block that only checked for SSE 2. A function that converts UTF8Strings that contain only ASCII characters to UnicodeStrings used an SSE 4.1 CPU instruction. But the SSE instructions are only used if there are more than 15 characters in the UTF8String. >> Might this relate to the problem I'm having with gnugettext ? In the context of IDEFixPack, the bug caused older CPUs to throw 0xC000001D "illegal instruction" exception. I'm not seeing the exception, but I think there is an exception in the call stack that I haven't yet been able to capture as it occurs.

@Kryvich In one of my tests I opened the dfm in Notepad++, changed the encoding from UTF-8 to ANSI and made another change so that it was saved. This didn't change anything. I normally have my dfm's as text - my issue was with a form, not a datamodule, though I doubt that makes any difference. I tried converting the dfm to binary, saving and then converting back to text, but it didn't make any difference with the previous version installed. I'm just happy now that I can use the pack - the IDE loads so much better.

Wow ! I would never have found that in my attempts to see what was going wrong. Many thanks.

@jbg I have tested uData.pas as well as a couple of my other projects. All good. Many thanks for this fantastic helper. I am curious though. On Friday I created a new project in Rio that was very similar to one that showed the problem. The new one loaded without any problem. I was in the process of trying to make the projects as similar as possible to see what was different. The sample form I was about to load up was very simple, and quite different to uData.pas. Do you know what it was that triggered the error in some conditions but not others ?

My processor is AMD Phenom II X6 1090T. @Kryvich uData generates the error on my machine.