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.
Related
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.
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.
I have an odd intermittent crash that only occurs under some circumstances that I am having trouble solving, and I'm seeking SO's advice for how to tackle it.
The bug
At apparently random points, Windows shows the "[App] has stopped working" dialog. It is an APPCRASH in ntdll.dll, exception code 4000001f, exception offset 000a2562. Here's where it gets tricky: this only occurs when running the application under the debugger. However, the debugger does not catch this exception, and at the point where Windows shows this dialog, the IDE is not responding. This bug does not occur when running normally, i.e. not within the IDE debugger.
I can't reproduce it outside the debugger, so I can't run the program and attach when it's already crashed. I can't pause execution when Windows shows this dialog, since the IDE isn't responding. I can manually trace through lines of code to see where it occurs. There are several, and where it occurs is apparently random. For a while it occurred when showing a window (or new form), for a while when creating a thread.
Edit: I have tracked it down to the IDE: if I pause on a breakpoint and click the Thread Status tab, the program will crash immediately with the above dialog even though it is, theoretically, paused. In this situation, the IDE remains responsive. This is really weird.
More information
I have just moved my development environment to VMWare Fusion. The bug also occurs running a build from my old (native Windows) computer on my new computer; it did not occur with the same EXE file on that old computer. This makes me wonder if it is related to Fusion or something in my new setup.
I am running:
Windows 7 Pro x64 on WMWare Fusion 3.1.3 on OSX Lion 10.7.1, all fully updated. Fusion is running in "Full screen" mode on one of my screens.
A colleague running Windows 7 natively (not in a VM) does not encounter this issue. Nor did I on my old Vista computer.
Embarcadero RAD Studio 2010, fully updated (I hope; there are about five updates and getting them all in order is tricky.) I have DDevExtensions 2.4.1 installed, and the latest IDE Fix Pack too: uninstalling both these has no effect.
The application is written mostly in C++, with snippets of Delphi. It is 32-bit.
We use EurekaLog, but the exception is not caught by it either. (Normally, an exception would be caught first by the debugger, then by EurekaLog.)
Running a debug build (no EurekaLog, extra debug info etc, debug DCUs set to true) also reproduces it. However, the "Debug DCUs" option on The Delphi Linking page of the C++Builder project settings dialog seems to have no effect - I can't step into the VCL code and find the line that actually triggers the error.
Codeguard (which detects memory access errors, double frees, access in freed memory, buffer overruns, etc) reports nothing.
This has all the hallmarks of a memory corruption. It only appears when you run under a one particular environment, and occurs at a different location each time. Both classic symptoms.
The best way I know to debug this is to download the full FastMM and run with full debugging options enabled.
If that doesn't help then you are reduced to removing parts of code, one by one, until you can isolate the problem.
Another problem I have seen in D2010 is a problem when mixing local class definitions (i.e. class inside class) with generics. The code generated is fine but the debug DCUs are wrong and when stepping through the code the debugger jumps to the wrong file and dies shortly after. You don't seem to have quite the same problem but there are similarities in the IDE deaths.
Finally I would advise you to suspect your own code rather than VMware. It's always tempting to blame something else but in my experience, whenever I have done so, it was always my code in the end!
I hit a quite similar problem. I've also been developing a .dll and when I've set a breakpoint anywhere in my code, Delphi stopped at the source code line and the host-application crashed immediately.
Closing the "Thread Status Window" in debug layout "fixed" the problem.
I'm working on Windows 7 64-bit and Delphi XE3.
4000001F is STATUS_WX86_BREAKPOINT
In other words, it is INT 3, which was not handled by IDE.
Since it is raised in NTDLL - I would guess that this is indication of memory corruption in system heap. Remember, some Windows code would switch to debugger version when running under debugger. That's why you can not reproduce this when application is running as standalone outside of the debugger - because breakpoint is not generated.
You may try FastMM in full debug mode, but I do not think that it will help you. The corruption does not happen in your memory, it happens in system memory. Yes, perhaps memory allocation scheme will be changed - and your corruption will reveal itself in your code/memory... may be. Try use top-down allocations, try use SafeMM...
Another possible approach would be using Application Verifier.
See also:
Windows has generated a breakpoint
C++ error on Ms Visual Studio: "Windows has triggered a breakpoint in javaw.exe"
http://blogs.msdn.com/b/oldnewthing/archive/2012/01/25/10260334.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2013/12/27/10484882.aspx
Check the The projects dsk file and make sure it does not have a reference pointing to the wrong unit. The fix is to open the dsk in an editor and change the file location to the correct location.
I get an access violation when call a DLL in an project. Both project and dll are use Chart unit (TChart). Remove Tchart from project the LoadLibrary can successful return. It also works if Tchart removed from dll. I don't understand why the chart unit can't be used in both project and dll? And how to resolve this problem.
Sarah, this is a bug of the TChart component, located in the TeCanvas unit. the people of Steema are aware of this. you can check the next Thread Delphi XE, TChart in exe and in dll in the embarcadero forums.
I spotted this bug today while using Delphi XE and FastReport 6 VCL, when in exe I have FrxChart and in a library.
After long time consumption debugging process, I realized that only TeEngine included in both application can cause crash LoadLibrary() function.
Because link to forum is not working anymore, can I do something to repair this bug (excluding remove charts in library)?