Delphi 10.4
Re: Delphi 10.4
Please run the installer again and make sure you installed madExcept 5 and not madExcept 4. Only madExcept 5 supports BDS21.
Re: Delphi 10.4
We've been testing the current BETA for Delphi 10.4 and discovered an issue with 64bit builds, if we have the compiler flag "DEBUG" defined. The application crashes with an AV, during the initialization. It seems that something goes wrong during some memory allocation code that is triggered by madExcept64.dll.
I'm not sure what exactly is the trigger in general, but I have attached a callstack where you can see what causes it in our case (the creation of an image list), so that you hopefully might be able to reproduce it, using a similar callstack:
I'm not sure what exactly is the trigger in general, but I have attached a callstack where you can see what causes it in our case (the creation of an image list), so that you hopefully might be able to reproduce it, using a similar callstack:
Re: Delphi 10.4
Using Delphi 10.4 and madExcept beta for BDS21. Users of Windows 10 prerelease 200612-1734 reported an issue with the 64bit build of HeidiSQL, where the application starts but just runs in the background, showing nothing but the taskbar icon. I already compiled a version without madExcept, which works fine as the user said. Not sure if that is really caused by madExcept, it may be caused by that Windows pre-release. Just wanted to let you know.
Re: Delphi 10.4
FWIW, you seem to be using either leak reporting or "instantly crash on buffer overrun", is that intentional? If you don't use either of these features, madExcept64.dll isn't used at all.SSchaefer wrote:We've been testing the current BETA for Delphi 10.4 and discovered an issue with 64bit builds, if we have the compiler flag "DEBUG" defined. The application crashes with an AV, during the initialization. It seems that something goes wrong during some memory allocation code that is triggered by madExcept64.dll.
I'm not sure what exactly is the trigger in general, but I have attached a callstack where you can see what causes it in our case (the creation of an image list), so that you hopefully might be able to reproduce it, using a similar callstack
Can you reproduce the problem with a simple test project?
Re: Delphi 10.4
Strange stuff. I don't suppose you can reproduce this at all on your dev PC?Anse wrote:Using Delphi 10.4 and madExcept beta for BDS21. Users of Windows 10 prerelease 200612-1734 reported an issue with the 64bit build of HeidiSQL, where the application starts but just runs in the background, showing nothing but the taskbar icon. I already compiled a version without madExcept, which works fine as the user said. Not sure if that is really caused by madExcept, it may be caused by that Windows pre-release. Just wanted to let you know.
Re: Delphi 10.4
No, for me that works in either 32 and 64 bit, without problems. Also, I have no feedback from users with a regular Windows version reporting such an issue.madshi wrote:Strange stuff. I don't suppose you can reproduce this at all on your dev PC?
In the meantime the forum guy mentioned that two other applications show the same issue on his Windows pre-release. Assuming these two don't use madExcept, this makes it more likely to be a Windows issue, not with madExcept.
-
- Posts: 28
- Joined: Mon Jan 03, 2005 3:03 pm
- Contact:
Re: Delphi 10.4
Hi, we can reproduce the issue where a 64-bit version of our software with madExcept will not start. I removed madExcept from the 64-bit version and it now works. This is with Delphi 10.3.3 and Windows 10 Pro x64 Build 20150 pre-release. We have old unsupported versions of our software that has the same issue (compiled with older versions of madExcept and Delphi) which we cannot release a fix for, so I just hope it's something Microsoft fix.
Re: Delphi 10.4
It took us a little to figure this one out, but the attached project should show the behavior ..FWIW, you seem to be using either leak reporting or "instantly crash on buffer overrun", is that intentional? If you don't use either of these features, madExcept64.dll isn't used at all.
Can you reproduce the problem with a simple test project?
Main steps:
- Disable the 'report resource leaks' option in the MadExcept settings
- Call StartLeakChecking(False) (we do so during the initialization of a shared unit to keep consistency within all projects)
- Create a DataModule
- Attachments
-
- LeakCheck_AV.zip
- (53.37 KiB) Downloaded 317 times
Re: Delphi 10.4
Does it make sense to call StartLeakChecking if leak reporting is disabled? I'd suggest you modify the code like this:
This conditional define is automatically set/removed by madExcept when you activate/deactivate the "report resource leaks" option in the madExcept settings.
Code: Select all
{$ifdef LeakChecking}
StartLeakChecking(False);
{$endif}
Re: Delphi 10.4
We usually activate the leak reporting for debug builds only, This allows us to test the application internally and publish a version without the check (as it is faster without the check and it would irritate most of the users more, than we would benefit from it). As the .mes file is the same for both build targets, we would have to rely on {$ifdef debug} and keep it disabled by default.
Re: Delphi 10.4
Hello @madshi! Do you have any update on this already? I wouldn't want to push it, but some of our projects are currently failing (as they already started to migrate to Delphi 10.4, not knowing about this issue), and we would have plan whether to wait on a fix or to revert back to Delphi 10.3. Thank you!
Re: Delphi 10.4
Hi again! May I ask for an update on this again? Thank you!
Re: Delphi 10.4
For users with a Windows pre-release or insider build: Windows 10 Insider Build 20161 now seems to have no issue with the madExcept 64 bit any longer.
A user of HeidiSQL just reported so: https://www.heidisql.com/forum.php?t=36542#p36546
A user of HeidiSQL just reported so: https://www.heidisql.com/forum.php?t=36542#p36546
Re: Delphi 10.4
@Anse, that's great news, thanks for letting me know!
@DanielT, I just tried your test project with Delphi XE8 and it crashes, as well. So it's not specific to 10.4 at all, from what I can see.
Generally, activating leak checking at runtime, while having leak checking disabled in the madExcept settings dialog is not a good idea because leak checking requires replacing the memory manager, and if you do that "late" that means you have allocations done by the old memory manager and allocations done by the new memory manager and then if the code tries to reallocate something, which memory manager is responsible then? If you ask the wrong memory manager to reallocate, it will create an exception because it doesn't know the allocation. And that is exactly what appears to be happening in this situation.
If you want to use leak checking, it's recommended (maybe even mandatory) to enable leak checking in the madExcept settings when you compile your EXE. You can then disable/reenable leak checking at will. But telling madExcept at first to not do leak checking and then trying to disable it at runtime later is problematic due to the memory manager issue described above.
@DanielT, I just tried your test project with Delphi XE8 and it crashes, as well. So it's not specific to 10.4 at all, from what I can see.
Generally, activating leak checking at runtime, while having leak checking disabled in the madExcept settings dialog is not a good idea because leak checking requires replacing the memory manager, and if you do that "late" that means you have allocations done by the old memory manager and allocations done by the new memory manager and then if the code tries to reallocate something, which memory manager is responsible then? If you ask the wrong memory manager to reallocate, it will create an exception because it doesn't know the allocation. And that is exactly what appears to be happening in this situation.
If you want to use leak checking, it's recommended (maybe even mandatory) to enable leak checking in the madExcept settings when you compile your EXE. You can then disable/reenable leak checking at will. But telling madExcept at first to not do leak checking and then trying to disable it at runtime later is problematic due to the memory manager issue described above.
Re: Delphi 10.4
@Madshi: You are right, this issue is not specific for Delphi 10.4, but for MadCollection 2.8.8.99, which is required for Delphi 10.4.
We are using this exact code with Delphi 10.3 and MadCollection 2.8.8.0 for years already, without a problem and (as far as I see) in accordance with the documentation (http://help.madshi.net/madExceptUnit.htm)
We are using this exact code with Delphi 10.3 and MadCollection 2.8.8.0 for years already, without a problem and (as far as I see) in accordance with the documentation (http://help.madshi.net/madExceptUnit.htm)
Which other way would you recommend to enable leak checking for specific build targets only?Leak checking is normally turned on/off globally in the madExcept settings dialog. However, you can also activate it manually, even for specific threads, only, if you prefer it that way. Furthermore you can also explicitly tell madExcept to not report a specific handle or pointer as a leak. Doing so makes sense if you have an "intentional" leak somewhere or madExcept gets confused about a specific handle or pointer for some strange reason.
// You can start/stop leak checking at runtime.