I'm getting:To prevent an unsafe abort when evluating the function 'System.Reflection.MethodBase.Invoke' all threads were allowed to run. This may have changed the state of the process and any breakpoint encountered have been skipped.
I have read previous solutions in this forum to this solution such as enabling legacy mode to no avail and have disabled -Enable Property Evaluation and other implicit function calls to no avail.
Has anyone found another solution to this problem? I have VS Enterprise 16.4.4 and the issue persist.
Related
I have a DPK project which sometimes shows errors ("out of memory") while compiling (into Delphi IDE), and sometime it compiles with success.
But, when I try compile it through the MSBUILD, it always throws this error message:
error F2084: Internal Error: AV004A784A-WFFFD3764-1
Someone have an idea to solve it?
An internal error like that is a compiler error. We cannot solve them, only the compiler developer can do so. You need to submit a bug report to Embarcadero. Given the antiquity of XE3 you are unlikely to ever receive a fix.
Modern versions of Delphi are less prone to out of memory failures so if upgrading is an option then doing so will likely side-step the problem.
If upgrading is not an option then you are probably going to have to keep muddling along and cursing every time you encounter one of these errors.
This is actual very common (at least i experienced these kind of errors very often). I did go with the approach to remove source code files step by step from the DPK until compiling works. This way you also see which file is causing these errors, then go ahead and outcomment source code parts in this file step by step until you find the offending line, then rewrite it (in what way you need to find out yourself).
As David Heffernan already said, there is no way you can really solve it, because the error is internal to the compiler or linker, and only the developers of these can remove that bug.
But often, there are some workarounds.
In my experience, such internal errors are often related to generics and anonymous methods, or to inlined code, especially if two or all of these are combined.
So find out what code change you made before the internal error occurred. If you use a versioning system, or Delphi's internal _history system, restore to a previous version until the error goes away. Then you can do a difference with your "offending" code and see which code caused the internal error.
Often, too complex expressions (especially for the types I mentioned above) cause internal errors. If that is the case, try to simplify the expressions by calculating subexpressions first. Also, instead of using ad-hoc generic declarations like
x := TList<SomeType<Integer>>.Create;
you should try to use pre-defined types:
type
SomeTypeInteger = SomeType<Integer>;
SometypeList = TList<SomeTypeInteger>;
...
x := SometypeList.Create;
In other words,
try to find the "offending" code by going back in your history until it goes away
once you have found it, try to simplify that piece of code. Disentangle expressions and predefine types
experiment with different ways to express the code until the error goes away
If you do that, you may be successful in avoiding the internal error. It has often taken me some time, but I have always found a way to achieve what I wanted. If you couldn't, ask about specific errors here (by posting the offending code, the exact error and if possible a Minimal, Complete, and Verifiable example).
Fortunately, these errors have become very rare in the newest compilers.
I have installed all Dsharp Packages in Delphi XE. But when I run the example, I always get the following error message:
Exception: Patching : ObjAuto.GetTypeSize failed. Do you have set a breakpoint in the method?
Has anybody found a workaround for this error?
The library is trying to apply a runtime code patch to fix a defect in the ObjAuto.GetTypeSize RTL function. The code that does this can be seen here: https://bitbucket.org/sglienke/dsharp/src/ad7c5983505f0117f1347f92d2bb96c07bdfda94/Source/Core/ObjAutoPatch.pas?at=master&fileviewer=file-view-default
The call to FindMethodBytes fails. Because this function is about to modify the executing code to install the runtime patch, it first checks that the code is as it expects it to be. It searches through the code looking for a known signature for that function.
That signature cannot be found and the patch therefore cannot be installed. Hence the error message. Some possible reasons for the patch code failing in this way:
A breakpoint is set in this code. Breakpoints are implemented by temporarily modifying the code to contain breakpoint instructions.
You are compiling and linking against your own modified version of the RTL. Because of this, the function signature is different.
Another unit in your program is also patching this same function, and the second attempt to patch fails for obvious reasons.
You are using debug DCUs that have a different signature from the standard DCUs.
There is a defect in the DSharp code. Perhaps an erroneous signature, that was not tested on your version of the Delphi RTL. That's not very likely. Perhaps you have installed a hotfix or Delphi update that has not been tested by Stefan. Or perhaps you have not installed a hotfix or update that you are expected to have installed. Maybe the linker has stripped so much code (or so little) that the signature search fails.
And the issue could be due to some other reason that I've not yet thought of. Fundamentally, though, these are all variants on the same theme. The code encountered at runtime is not as expected. I do recommend that you try to find out why so that you can determine how best to proceed.
Given that there are so many possible causes for this message, I've simply tried to explain the conceptual reason for it, but now it's really over to you to debug the specifics in your environment.
We use Embarcadero Delphi 2010 and recently a change was made to one of the units of a medium-sized project, causing code completion to stop working completely -- but only inside this project, it still works fine in other projects. Puzzled, I searched the interwebs for clues on what exactly could make this happen, but my search wasn't too successful.
From what I gathered, it looks like IDE has a few parsers/compilers that work completely separated from one another, which makes it entirely possible that the faster code-completion compiler could fail where the main compiler would not. Which is exactly what's happening to my project.
My question: Is there a way to find out WHERE exactly the Code Insight/Code Completion compiler is failing? Does the IDE keep a log of on-the-fly parsing/compilations anywhere?
Is there a way to find out WHERE exactly the Code Insight/Code Completion compiler is failing?
Not readily, not without debugging the IDE.
Does the IDE keep a log of on-the-fly parsing/compilations anywhere?
No.
I suggest that you install Andy Hausladen's IDEFixPack. If that does not help then use your revision control to isolate the code change that causes the problem. And find a different way to write that code that happens not to bork code completion. Trial and error is likely to be the most productive method here, much as I hate to say that.
I recently had the same problem using Delphi 10.2. After a lot of research I found that I had inadvertently declared a variable in a type section with an end; following on the next line. Removing the errors restored the code completion function. So I would recommend combing the interface for an error or restoring a backup from the directory history.
We've got an application written in Delphi that uses Delphi On Rails and acts as a server and communicates with clients using HTTP, JSON and websockets. We ran into some issues lately and it's hard to debug them and find the problem's source.
Using Wireshark for traffic analysis, we could see the following behaviour: There's a request from a client (HTTP GET for a file). Usually, we process that request and send a HTTP status code, the file (if not cached) etc. However, we have a reproducable problem where there's only
the request from the client, a TCP SYN from the server, but after that, the server sends a RST packet and the TCP communication stops.
The strange thing is, we can reproduce the problem quite well (although the files where the RST packet disrupts the communication differ) and it mysteriously vanishes in one of the following cases:
In debug environment (Delphi IDE), disabling madExcept
In release environment, not patching the executable with madExceptPatch
Give focus to a different window than the main application window.
As we had some problems with Delphi On Rails and had to do minor modifications to it to avoid access violations and debug exceptions, I suspect DOR to be the culprit and some strange memory corruption or uncatched exception to be the bug, but it's still confusing, especially the fact that the problem vanishes if we change focus.
My main question is not how to solve this problem, but how to debug it and where to look for problems. The source of the TCP reset also puzzles me, as we don't run into the usual procedures that process requests in that case and it seems like either DOR or something else (the application, Winsock, OS) resets the connection by mistake.
For completeness, as it might be related, here are issues that I reported at the Delphi On Rails project and a forum thread where I asked the madExcept author about the problem: Issue #6, Issue #7, Issue #8, forum entry.
As a test, we checked out some older DOR sources from version control where no connection issues were known, and it works without showing any of the above problems.
So we decided to solve the problem the other way round: Rolling back the DOR specific source code (about 20 files) to the last stable version and "re-updating" it piece by piece until the error will occur again. If this happens, we can
Go back to the latest working version quickly
Hopefully be quite close to the original DOR sources so we can react on updates on the library.
Analyse the occuring error and report an detailed issue (and perhaps even a solution) to the DOR project.
EDIT: We could now update all but one file back to the old state without getting connection issues. The file that creates problems is dorSynchronizer.pas, more exact it's r179 of this file that caused the issues - threads were changed from Windows API to Delphi TThread there. We'll investigate this further and might add an issue to the DOR project in the next days.
EDIT2: It turned out that DOR uses the deprecated procedures TThread.Suspend and TThread.Resume that can cause undefined behaviour. I reported an issue to the DOR project.
I was wondering what strategies you guys are using to fix runtime errors? Really appreciate if you could share some tips!
Here is some of my thought (possibly with the help of gdb):
when runtime error happens because some memory is wrongly accessed, is the address stored in the dumped core showing where the memory is?
If I can find the address/memory whose being accessed causes the runtime error, is it possible to find out which variable is using that address (which may be at the begining or middle of the memory of the variable)? And find out the nearby variables that takes the memory down below and right above that memory block?
If all these are possible, will it help to fix the bugs?
Thanks and regards!
I use gdb's --args option to start my programs from the command-line.
Example:
gdb --args foocode --with-super-awesome-option
run
This will load the program foocode and pass the --with-super-awesome-option parameter to it. When the program fails, you'll have a ready-to-use gdb session to work within.
From there you can use the backtrace command:
bt
This will show you the chain of events (function calls) that lead to your crash.