Any idea why? I tried reinstalling it into different drives, but still no luck.
Had that same problem, for me was the windows defender blocking the bds.exe. Take a look at the protection history and see if it is being blocked there
Related
I have embarcadero radstudio xe8 on a windows 10 machine. Everything was working perfectly till about 2weeks ago. Everytime I try to start Delphi xe8 I get an error :"Exception EOSError in module rtl220.bpl at 00050A4D.System Error. Code 111. The file name is too long. " I tried reinstalling a couple of times and I even tried installing appmethod but I still get the same error.
What can be the problem?
I've had the same issue today. I've traced it to a GetAdaptersInfo() call, and it turned out that for some reason (VirtualBox is my main suspect) I've had over 50 network adapters registered on my system. Removing all of them fixed the issue.
There is not enough info in your question in order to tell what exactly is wrong. Try using Process Monitor in order to check what files Delphi is trying to access. It will also show the errors of these file operations.
as they uri2x tell you the problem is that RAD Studio having issue with many network adapters registered more than 20 will not work properly you will have problem with debbuging and run project and you may find many cmd.exe process running in your system
delete duplicate and non needed network adapters registered on "Control Panel\Network and Internet\Network Connections"
that will fix your problem
This may be of help. I had a similar problem, error code 5 Access is denied. This turned out to related to a thread started to test an internet connection on an embedded panel (using BeginThread). If the user exits the form (which is testing the internet connection) immediately after displaying the form, the AV occurs.
On my development PC, the internet connection test was successful...and so fast I never saw the problem! After struggling for several hours, I finally tracked it down to this thread and reproduced it by disconnecting my network cable.
The solution was straightforward: When exiting the form (eg. in the FormDestroy event) ensure the thread is definitely not running before continuing.
I am running plink software through a PBS batch job. This error occurs when I run the job:
*** glibc detected *** /software/plink: double free or corruption (out): 0x000000018dfafca0 ***
======= Backtrace: =========
[0x7d7691]
[0x7d8bea]
[0x45f5ed]
[0x47bb11]
[0x40669a]
[0x7bdb2c]
[0x400209]
However it only occur with one of my files (bw 30-60 gb files) and each rerun shows the exact same back trace map. I tried running it not through the batch scheduler and received the same error again, with the same backtrace map. I am just using the software (plink), and didn't write it, so most of the answers online are about writing and freeing memory in your program.
Any ideas on
what is causing this error, and
how I can fix it?
what is causing this error, and
A double-free or heap corruption in the plink
how I can fix it?
You can't. You can do one of two things, depending on how much you know and understand.
First, build the newest version of plink from source, and see if the problem persists.
If it does not, you are done (or at least you might hope that someone else found and fixed this problem).
If it does, you'll have to debug the problem sufficiently for either you, or plink developers to fix it. Some tools that should help: Valgrind and Address Sanitizer (note: in addition to Clang, Address Sanitizer is also included in GCC-4.8).
Once you have a good report (where the memory was allocated, and where it got corrupted), you should either fix it and submit your fix to plink developers, or give them a bug report with the allocation and corruption location and stack traces.
I develop with Delphi 2010 in a VM, the app runs well inside the VM in any ways within the ide, alone with or without Eurekalog using mainly DevExpress grids and AidAim SQLMemtables.
When the same App is ran on the host (ie directly on windows) the eurekalog finds memory leaks on the SQLMemtable dataset component and sometimes but often enough to make it impossible to release it crashes on a simple Dataset.refresh. It is very hard to debug because in the debug environemnt it works.
Anyone would have any idea what is going on, I am at loss of ideas here
Thank you for your help
Regards
Philippe Watel
Your external dependencies (dlls) differ on both machines? Also consider using Delphi's remote debugger and log more details to find out more details about your problem.
Users have been reporting problems/crashes/bugs that I can't reproduce on my machine. I'm finding these problems difficult to fix.
I've started using EurekaLog (fantastic!) and SmartInspect. Both these tools have helped greatly but I'm still finding it difficult to catch some problems.
I've just purchased Debugging by David Agans (and waiting for it to arrive).
Are there any other tools or techniques specific to Delphi that will help with catching these hard to find remote problems? The kinds of problems I'm finding difficult to track down are those that don't raise exceptions or have a clear cause. EurekaLog catches exceptions and SmartInspect is pretty good once I have a theory to check. But in some cases it is a seemingly random crash and there are several thousand lines of code that may may be at fault. How to narrow down to the root cause?
MadExcept is what I use, and it is fabulous. I have also used EurekaLog and find the functionality almost exactly identical, except that I have more experience and time using MadExcept. it's free for non-commercial use, and reasonably priced for commercial use.
Update: MadExcept 4 is now out and even supports 64 bit Delphi XE2 apps, and has memory-leak checking too.
When nothing blows up, I rely on heavy use of trace logging. I have a TraceMessage(integer,string) function which I call throughout all my apps, and when someone has problems I get them to click a menu item that turns up the debug trace level to the most verbose level; it gives me a complete history of everything my application did, and this has helped me even more than madExcept, to solve problems at customer sites. Customers get a crash, and that crash report sent by madexcept contains a log file (created by my app) that is attached automatically. I believe you can do this equally well with madExcept and EurekaLog. If you need a logging system you could download Log4D, or you could write your own, it's pretty simple.
For always-free, try JclDebug, which requires more work to set up, but which has worked fabulously for me, also.
For help with heap problems, learn more about fastMM (full version) debug options.
And you shouldn't forget that Delphi itself supports Remote debugging, if you can reproduce a crash on machines in your office that don't have delphi installed, use remote debug across the office network instead of installing a complete RAD Studio installation on that other machine at your work. You could also use remote debug to connect to a client PC computer across the internet, but I have not tried remote debug across the internet yet, so I can't say whether it works great over the internet or not. I do know that since remote debug doesn't support automatic deploy of the EXE file you built (you have to do that part yourself), remote debug over internet, to a client PC is more work.
You might also find lots of your problems by fixing all your hints and warnings, and then going through with CodeHealer or Pascal Analyzer (PAL) from Peganza. These static analysis tools can help you find real code problems.
If performance and memory usage are your problems, get the full version of AQTime, and use it to profile and watch your system operate. It will help you fix your memory leaks, and understand your app's runtime behaviour and memory usage, not just leaks but bottlenecks for memory and CPU usage. Some of those bottlenecks can also be the source of some odd problems. I have even used AQTime to help me find deadlocks, since it can generate traces of execution, that can help me figure out what code is running, and locate deadlocks. Update: AQTime is not installable on machines other than your main dev machine, without violating the newly modified license terms for AQTime. These terms were never this restrictive in the good old days.
If you gave more exact idea of what your problems are, I'm sure other people could give you some more ideas that are specific, but all of the above are general techniques that have served me well.
One of the best way is to use the Remote Debugger that comes with Delphi, so you can debug directly the application running on the remote machine. THe remote debugger is somewhat buggy in some Delphi releases, and requires to follow the instructions carefully to make it working, but when needed it's a tool to consider. Also check if there are updates available for your version, they could come in a separate installer for deployment on "remote" systems. Otherwise first install the remote debugger, than check if the files installed has newer versions in your local installation, and the copy tehm on the remote machine.
CodeSite has helped me a lot in these situations. Since XE it is bundled with Delphi.
Logging is the key, in this matter.
Take a look at our TSynLog class available in our Open Source SynCommons library.
It does have the JCL Debug / MadExcept features, with some additional (like customer-side profiling, and logging):
logging with a set of levels;
fast, low execution overhead;
can load .map file symbols to be used in logging;
compression of .map into binary .mab (900 KB -> 70 KB);
inclusion of the .map/.mab into the .exe;
reading of an external .map to add unit names and line numbers to a log file without .map available information at execution;
exception logging (Delphi or low-level exceptions) with unit names and line numbers;
optional stack trace with units and line numbers;
methods or procedure recursive tracing, with Enter and auto-Leave using interfaces;
high resolution time stamps, for customer-side profiling of the application execution;
set / enumerates / TList / TPersistent / TObjectList / TContainer / dynamic array JSON serialization;
per-thread or global logging;
multiple log files on the same process;
integrated log archival (in zip or any other format);
Open Source, works from Delphi 5 up to XE.
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.