I've faced a really odd behavior of Delphi VCL Styles. With VCL styles enabled, and when madExcept has the "instantly crash on buffer overrun" option activated, the menus become non-styled.
Turning this option off, or switching it to "instantly crash on buffer UNDERrun" fixes the menus issue.
Questions are: did anyone else encounter this issue? Why it happens and how to fix it?
This issue is caused by a internal call to the GetClassName WinAPI function. I just tested and uploaded a fix for that. So you can download the last version of the VCL Styles Utils project from the repository, then add the units Vcl.Styles.Utils.Menus, Vcl.Styles.Utils.SysControls and Vcl.Styles.Utils.SysStyleHook to your project and finally comment or remove the Line (27) {$UNDEF UseVCLStyleUtilsMenu} in the Vcl.Styles.Utils.Menus unit.
That seems to indicate to me that the VCL styles code has a buffer overrun. The madExcept memory manager is succeeding in making that buffer overrun manifest as an exception. In turn the styles code responds by disabling styles.
The next course of action is to run the code under the debugger, with debug DCUs enabled so that you can debug the VCL code. Hopefully the debugger will catch the exception and then highlight the buffer overrun.
If you succeed in identifying the problem you can make a workaround and submit a bug report to QC.
Related
I like to use Codeguard utility to detecting array range and memory leaks. Unfortunately, cg doesn’t work in RAD studio 10.2 for me (we have an installation of 10.2 on three computers and same problems). When CG detect problem in code it freezes and no line highlight in debugger. In cgl file there is nothing or one or two lines of text – no more. This was tested on small VCL project with one main cpp file. Does anybody know what can be configured to solve this problem? On older version XE7 there is no problem with CG and I was widely use this.
So, I am trying madExcept. Can madExcept detect array overrun problem like this:
int array[10];
array[10]=0;
For me with default configuration nothing is happen when code steps on array[10]=0 (but CG in previous version of rad can detect like problem). And when program is finished madExcept says: no leak detection. Can madExcept detects this kind of overruns or not?
An alternative to MadExcept might be EurekaLog, but I can't tell, as I use MadExcept in Delphi which works for me.
I am experiencing a crash / exception when using a simple TOpenDialog with VCL Styles enabled.
Without the styles enabled, the dialog is of course working fine. The issue occurs with C++ Builder 10 and 10.1 Professional.
To reproduce:
create a simpe VCL Form that uses styles
add a TComboBox, a TButton and a TOpenDialog to the form
add the following code to the OnClick event for the button
OpenDialog1->Execute();
for(int i=0; i<100; i++)
ComboBox1->Items->Add("test text");
ComboBox1->ItemIndex = 1;
run the application, click the button and select a file
For me, this yields to an exception 'Out of system resources'
This bug could be reproduced on Windows 7 Enterprise and Windows 8.1 Pro.
Having the same issue with a TSaveDialog.
The weird thing for me is that regarding this exception, I can't find similar issues on the web. In my opinion, with only VCL styles and TOpenDialog required to have this, I would expect more information about this on the web.
I only found something remotely similar, but not an exception there and also no solution in terms of native VCL styles:
Using custom styles shows invalid characters when right-clicking a file in TOpenDialog
I tried also to disable SystemHooks shDialogs (please see screenshot) which I read somewhere regarding another problem with VCL styles, but to no avail.
* Edit 2016/05/26 *
Remy Lebeau is asking for a MCVE. I tried to put everything in the question, but for clarity here an abstract for a MCVE:
create new VCL project with default settings
drop a TComboBox, a TButton and a TOpenDialog into the form
add the following code to the OnClick event for the button:
void __fastcall TForm1::Button1Click(TObject *Sender)
{
OpenDialog1->Execute();
for (int i=0; i<100; i++)
ComboBox1->Items->Add(L"test text");
ComboBox1->ItemIndex = 1; // <- exception occurs here
}
enable a VCL style 'Smokey Quartz Kamri' in the project options
run program, press button, select any file and select OK in TOpenDialog
Here, this is really all it takes for the exception.
In my opinion, the call to Execute() messes up some VCL structures (only if styles are enabled) and then the access to another VCL item (combobox in my case) leads to the crash.
I am now aware that not every one has this crash. So forgive me if it is not a 100% verifiable example for each of you.
But me and my colleague can't be the only ones who have this crash (tested now on 4 different computers with 3 different OS versions), can we?
* Edit 2016/05/27 *
Regarding Tom Brunberg's request for single step, the exception occurs somewhere within WndProc, in the screenshot at address 005459F4 within the call.
If I step further, I am landing somewhere in TCustomCombo.WndProc. After that is is very hard to follow further because of repeating loops in WndProc, can't seem to reach the final place where the exception fires.
* Edit 2016/05/27 second *
OK I managed to pinpoint the exact location of the crash. Is in in the function CopyBitmap within VCL.Graphics. In the first screenshot, exception occurs at line:
Result := GDICheck(CreateCompatibleBitmap(ScreenDC, bmWidth, bmHeight))
In the function GDICheck() in the second screenshot, the variable Value is zero in the debugger, so in turn function GDIError is called. There, ErrorCode is zero as well, this leads to the call to OutOfResources.
Hope this helps to narrow it down further.
* Edit 2016/07/19 *
Since nobody here seemed to have the issue, we gave it a different try:
A colleague of mine in the company did a fresh C++ Builder 10.1 Berlin install, in English (thought maybe the German IDE is the culprit),
and first thing after the install, recreated the StylesCrashTest App. Result is the same, it crashes at once after selecting a file and hit 'open' in the dialog.
I have uploaded the test project here
http://fboom.me/file/9904e22ddd22b/StylesCrashTest.zip
and our generated release exe here
http://fboom.me/file/368d0b62cc1a7/StylesCrashTest.exe
The exe is tested with many antivirus scanners on virustotal.com.
https://www.virustotal.com/de/file/e96f2e7eb80c162c2e5998decc15f26615c9fc76efec73379dd2e2140e4eba08/analysis/1468952442/
It would be helpful if you guys could test the exe and the test project and this could lead to separate the issue to either computer related or related to the installed IDE/generated exe. This of course only if someone can reproduce the issue.
With this exe, the app crashes here on two Windows 7 x64 Enterprise computers in a commercial environment.
It does not, however, crash on my private computer with Windows 8.1 x64 Prof.
Right now I am at a dead end, nobody outside the town of Munich seems to be able to reproduce the issue, but we have it definitely on two different computers.
The issue is also filed with Embarcadero (login required):
https://quality.embarcadero.com/browse/RSP-15019
Sadly, at the moment, this is a shop stopper for us for using VCL styles.
I found a fix to get rid of the crash. After some more debugging, it was discovered that the exception occurs every time TBitmap::SetSize is called with a negative parameter on the VCL styled TComboBox.
Please see the call stack in the attached screenshot:
TComboBoxStyleHook::ListBoxWndProc
TComboBoxStyleHook::DrawListBoxVertScroll
TBitmap::SetHeight
TBitmap::SetSize
After editing SetSize() in Vcl.Graphics.pas to exit on negative numbers the exceptions seems to be gone.
This is no fix for the cause of the exception, because why the parameter is set to -1 in DrawListBoxVertScroll is still unknown (bug?, could also be the result of a lot more sub calls within this routine), but at least it is
a fix to prevent the exception. Tested on all our machines where the exception took place with positive results.
Would love to hear the opinion of some real VCL experts like Remy Lebeau or even the VCL developers about it, though.
Again, I realize that not everybody can even reproduce the exception, but with the test project linked above, the exception is inevitable on our systems.
In a Delphi Project CTRL + Space not working.
Before "uses" when I Press CTRL + Space the code completion is appeared but after "uses" does not appear.
I use Delphi 2009.
I install Fastreport and raize components and vcl Skin.
The most probable cause for your problem is that you have some smal syntactical error like missing semicolom, invalid name, etc. somewhere between the point where CTRL+Space works and where no longer works. This is due the way how Code Insight is checking the code structure.
So I recomend you go to menu Project and then chose Syntax Check.
Another cause for CTRL+Space not working is that your are still debuging your program. Do nte that while debugging sesion is in progress both Code Insight and Error Insight are disabled.
Something that in general wreaks havoc with Code Insight (Ctrl+Space) is conditional compilation.
So watch out for {$IFDEF ...} in your code.
I prefer to avoid conditional compilation in anything except library code that needs to support multiple Delphi versions. However, if you must use it, consider inverting the logic so you can use {$IFNDEF ...}.
Also, the feature doesn't always work if your code cannot compile. This depends on what dependencies are unable to compile at the point where you press Ctrl+Space.
However, in my experience the feature does sometimes just "break". If you're lucky closing and re-opening the project fixes it. But usually I have to close and re-open Delphi and do a full rebuild of the project.
I had the same problem I press Ctrl+Space to all units in uses section and I see one unit Delphi can't recognize. I delete it and type it again with Ctrl+Space; after that everything is ok.
another reason is if exists a special character like a tab character in your unit.
The "So watch out for {$IFDEF ...} in your code." had this. Temporarily did a Ctrl-X on it and then did Ctrl+Spacebar and pasted the code back in. Then... it worked again. Delphi XE10.1 Update 2. Other reasons why it sometimes doesn't work still remain a mystery. Can be very frustrating indeed.
I have a frame that never had any problems before. Now when I am in the Delphi 6 IDE and I try to draw an instance of it on a Form in design mode, the IDE exits immediately without any crash errors, dialog boxes, or Watson style "please report this error" message boxes. I am running on Windows XP and I have never seen the Delphi IDE do this before. The frame doesn't even have any of my custom components on it, just some of the stock Delphi VCL components and a few third party components from a library that I have used without trouble for years. I tried several other frames resident in my project and I can still create those at design time without error.
Note, I did try a complete clean of all project DCUs and rebuilt several Delphi packages for my custom VCL components just in case but those efforts changed nothing.
Does anyone have any tips for diagnosing and fixing this problem?
It is possible to configure Delphi to debug itself. You launch a second copy of Delphi, and you might be able to see where in your code, and the only reasonable thing I can assume is that suddenly there is a problem with the code of the third party library components. To locate the source and line number of that crash, the Delphi debugger itself may be of some use.
Simply launch the third party component with Delphi.exe as the host executable (for Delphi 6 and 7), or bds.exe (for more recent Delphi versions). (In the IDE using Run Parameters, in the Host Application, put delphi.exe or bds.exe)
Then once you've located the source of the exception and fixed the code and recompiled the component packages containing that code, your problem may be solved.
Related answer by me
(Note that the madExcept idea is equivalent in that it might also give you a stack traceback to help you find what code is crashing, but in case it doesn't this technique is also valuable to know about.)
I have a 3rd-party component that causes the Delphi IDE to stop responding (hang) when I try and close a project that has a form containing the problem component in it.
Is there an easy way to track where in the component's code the problem could lie?
Would it be reasonable to say that it is in the destructor of the component?
What steps would be recommended to try and narrow down the cause?
madExcept does not show anything so it does not seem to be an access violation problem.
Thanks for kind assistance.
The same way you'd track down any other problem: Use the debugger.
Start Delphi and open a project. Set the project's "host application" to be Delphi itself. Run the project in the debugger, and another instance of Delphi should appear. In the new instance, reproduce the bug. When it hangs, go to the debugger (the first Delphi instance) and pause execution. Look at the call stack and find the bug.