Related
From time to time, when I load a project into the XE6 IDE, the following error occurs
This error results in the TZConnection component being removed from the Datamodule for some inexplicable reason. Note that the project has been loading without issue for ages and just out of the blue, this occurs.
Has anyone seen this before and know of a way of stopping it from occuring ?
It also occurs with other components, not always the TZConnection component but mostly ZConnection.
Like I said before, this appears randomly. I could close project A, open project B then close it and return to Project A and bang!, the error occurs.
Any clues ? (note that this also used to occur in Delphi 2007)
The Zeos libraries are themselves causing this problem.
To see why, and to fix it, use Delphi to launch a second instance of Delphi, and debug the issue directly.
I wrote a blog post showing exact steps here.
The key is to set the executable that will be run for your zeos package, be sure to build them in debug configuration, and then click the Run button on the Delphi IDE toolbar. A second delphi instance will start. Open the affected form but be sure to be using the IDE instance that is Being debugged as opposed to the one which is currently doing the debugging, when the exception occurs that is causing your component to delete itself, you will be able to step into the package code and see the problem.
I suspect a DLL-hell path issue. (Multiple copies of Zeos or other core BPL/DLLs in your path.)
Actually, it doesn't sound that inexplicable - it's probably caused by an exception occurring as the DataModule (or some form with db-aware components connected to it via properties) is being loaded into the IDE (see below). Have you tried checking that wherever your ZEOS .BPL files are located is on your system Path? Likewise any .BPLs they depend upon - see the "requires" clause in the .DPK file(s) for Zeos.
This sort of problem arises fairly frequently with flaky DB components, maybe more so than other types of component because db components more frequently involve linkages between datamodules and forms, e.g. when db-aware components on the forms are connected to others on the datamodule.
So, sometimes, whether this sort of problem shows up or not depends on the order in which the IDE will re-open them - try closing the project with only the dm open and then re-opening it. A bit of experimenting with which datamodules and forms are open in the IDE and in which order may help you pin down the problem. If/when you have a reproducible sequence of steps to provoke the problem, report it to the authors.
A fairly reliable way to determine whether the problem is being caused by an exception as a project loads is to run one instance of the IDE inside another. As long as the first ("outer") instance of the IDE has the debugger set to "Break on Language exceptions" it should be able to take you straight to the source of the exception (assuming it occurs, of course) when the project is loaded by the second instance. It may take a few goes to "catch it in the act" of course, but it is hugely satisfying when you manage to. Good luck!
Unlike MartynA I doubt this would be caused by an exception.
I would more likely expect such issues to be caused by windows path environment variable being too long.
Unfortunately still many component vendors and even some programs modify "windows path environment variable` to make their own files accessible by other programs.
And when windows path environment variable fails to provide sufficient information windows will try to find the files in default system directory which is C:\Windows\System32
So I would strongly advise checking the windows path environment variable to check its length.
The easiest way to do this is by simply starting the command prompt and typing in path directive or perhaps path >> D:\path.log to export the path environment variable information into a file for easier reading in case if it is long.
EDIT: BTW I just checked my path environment variable and I see that I will have to do some cleaning because it contains entries for both Delphi XE8 and Delphi XE 10 Seattle file locations even thou I have removed Delphi XE8 from my computer. Not to mention some entries from some programs that I have removed quite some time ago.
Delphi 2007 sometimmes holds a handle to the EXE it's linker makes. Sometimes it works fine. But other times it's a whole day saying: "Cannot make EXE file" or something similar when trying to compile or build a solution.
When I try to launch EXE made from Delphi it says that another process is holding the file. Going to "unlocker" says: bds.exe. Even if I unlock it I must rename it to eg. app1.ex_ and copy it back to app1.exe. But still Delphi is holding the handle to that .ex_ file.
Needless to say it makes debugging (or even running) and developing quite slow: having to deal with locked exe...
Any suggestion? Workaroung or fix available - I've been looking for it but can seem to find it: I'm sure others have the same problems (I've seen it) - is there any fix for this?
env.: Win7 Ent. x64, Delphi CodeGear 2007
Thanks!
Going to "unlocker" says: bds.exe. Even if I unlock it I must rename
it to eg. app1.ex_ and copy it back to app1.exe. But still Delphi is
holding the handle to that .ex_ file.
Based on the fact that renaming file causes the BDS.exe to "hold the lock" of renamed file I seriously doubt the BDS.exe is actually the one that is holding the lock. If BDS would be holding the lock on that file you wouldn't even be able to rename it.
So I would seriously suspect that your AntiVirus software might be behind it.
I even remeber having similar difficulties years back using Delphi 7. The cause then was ma AntiVirus software (Nod32 version 2). First workaround I was unsing was to simply delete the application exe file prior compiling, but later I simply added entire Folder into the AV residental protection ignore list.
So try adding your project folder into ignore list and see if it solves the problem.
c++ Builder xe5 [ilink32 Error] Error: Unable to perform link
[ilink32 Warning] Warning: Error detected (LME288)
that happened when i tried to compile a test project
c++ builder xe5 on windows xp
I got some information on this from Embarcadero which may help.
The error is an "out of memory", error. The reason for "Out Of Memory"
errors (which come in different guises) in the linker, is that the linker
has to pre-allocate memory in contiguous heaps that it then uses as it
links, in the past these heaps could not be adjusted, we had to do a best
guess, so in the new 64-bit linker (and has also been added to the 32-bit
linker) we allowed people to be able adjust the size of these heaps manually
when they needed to. Now the reason why these heaps can be problem is that
not all systems are the same, some people use different software that map
DLLs into the linker's address space like Windows Hook DLLs, antivirus
software all these DLLs allocate memory INSIDE the linker's (any application
really) address space and hence has an impact on the size of the heaps the
linker can allocate. So we added this ability to adjust the heaps manually,
but we also allocated the initial heaps quite big .
The 32bit linker has a new switch -GH, see below this is similar to the
ilink64 switch.
The syntax for the switch is:
-GH[heap name]=[number of bytes for the heap]"
This option -GH exists from XE3 Update 1 onwards but evidently is not documented?
To see which heap is out of memory you can try from command line.
MSBuild /p:Platform=Win32 /v:diag XXXX.cbproj
This provides additional information such as:
Overrun on linker heap: code
Linker Heaps
info 0x002d0000 0x0a000000
code 0x000d0000 0x00100000
data 0x00030000 0x08000000
bss 0x08000000 0x08000000
Fatal: Out of memory
The left side of the above output is number of bytes being used at the
moment and on the right the number of bytes allocated for the specific named
heap.
The default heap sizes the linker allocates at start up are:
"system", default size 0x08000000
"info", default size 0x0A000000
"code", default size 0x08000000
"rodata", default size 0x06000000 //readonly data
"data", default size 0x08000000
"bss", default size 0x08000000
"tds", default size 0x0FA00000
When you see the "unknown heap" this is normally the "tds" heap
Example to adjust tds heap to 0x0A000000 you would do -GHtds=0x0A000000
Hopefully this information helps you and others with the LME288 error.
I got it.
I had the same problem with Seattle 10 on Windows 7x64. I tried it all. Everything you can find on SO, EDN, and more. I finally broke down and used my Embarcadero support ticket because I simply couldn't link anything anymore. After what I can only describe as an arduous and valiant effort by one of Embarcadero's senior software engineers, we finally stumbled across this fix:
First, right-click on ilink32.exe, select Properties, then go to the Compatibility tab and tick the "Run this program in compatibility mode for" checkbox and select Windows XP SP3. On my system (64 bit Win7, running Seattle 10) the ilink32.exe file is located in "C:\Program Files (x86)\Embarcadero\Studio\17.0\bin."
Second, force admin rights (even if you're already an admin) by right-clicking the Builder launch icon and selecting "Run as administrator."
Now, open your projects and link to your heart's content! (Your results may vary.)
I found this page looking for the same problem, and the solution for me is a simple trick:
Instead of double click in the project to open it (for example double click in xxxx.cbproj), start the ide and then open the project.
Explication? no idea, but now link correctly.
I had the same problem here C++ Builder XE7 LME288 Error
My solution was simple to clean up all temp files. It seems like the error is connected with corrupt temp files.
I just had this issue with XE4 on Windows 10. Fvel got me on the right track. The issue was being caused by the file being opened with BDSLauncher.exe instead of bds.exe . I set the default program for .groupproj to be bds.exe and the problem went away.
Disable your AntiVirus protection software for the ilink32.exe in the embarcadero bin folder, especially if you are using bitdefender.
The solutions given here did not work for me.
My solution is to set the size of the windows swap file to a fixed value (e.g. min: 1000 MB and max: 10000). After restart I checked the Radio Button to "System managed size" and restart again.
Now I can compile and link without any linker errors. But the LME-error comes up again after some days. Then I have to do the same steps with the swapfile to solve the problem.
For me, in Windows 10, the issue was because there wasn't enough Virtual Memory allocated.
Steps to resolve the issue:
Go to System > Advanced System Settings > Advanced.
Under 'Performance', click 'Settings' > Advanced
Under Virtual Memory click 'Change'
Ensure the currently allocated memory is equal to or greater than the recommended memory. If not, select 'Custom size' and set the initial size to the recommended size, and the Maximum size to a larger value.
See also C++ Builder XE7 LME288 Error
For me the problem started when I switched on Auto increment build number in XE7. The project I had had worked for several months without problem. The project was created by an earlier version of Builder. The first problem that occurred was problem for compiler to find windows.h, and the same for rc compiler. The PATHs was updated to invalid versions by Builder (perhaps these were from earlier Builder). After adding the PATHs the LME288 occurred.
After switching of the Auto increment build number and removed all temporary files it seems to work again.
I had the same linker issue LME288 on RAD Studio XE7 / Windows 10.
Cleaning temporary files using CCleaner fixed it.
Edit: the problem keeps coming back but another run of cleaning fixes it.
Delphi 6 Prof.
We have many applications. The programs have 8-12 MB size.
In this period we many times got reports about "Invalid stream format" errors.
We use shared Windows (or Linux) folders to store the applications, and users running them from these directories with links.
This meaning that OS is paging the files, and loading the needed parts only.
Formerly we got C000006 exceptions.
As I know this meaning that the file paging (loading) failed on any network problem (timeout, etc).
Now we face with "Invalid stream format" errors, and "invalid property xxxx" errors.
If I know well, both error caused by "paging problem", but C06 happens in code, and stream error in the data area of the Exe.
But maybe I know wrong...
Anyway the problem is strange. Sometimes we got it, sometimes we not.
How to avoid it? These errors prevents the users to create new dialogs, to use the programs...
(In other place the user used wifi - then we got same side effects.)
Maybe you have any idea how to prevent, avoid this problem.
UPX (vs. Antiviruses)?
Copy the exe-s to local place?
The system administrators of this customer are "our enemies", because they said: "everything is ok". The source of the problem isn't identifiable...
Thanks for every idea: dd
Assuming your analysis is correct, and the problem is that the executable is located on a network drive with a flaky connection, then there is a solution. You need to add PE flags to your executable that forces Windows to copy the file from the network to the local machine before running it.
Make sure that your .dpr file's uses clause includes the Windows unit. And then add this line:
{$SetPEFlags IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP}
just before the begin in your .dpr file. We added the Windows unit so that the two constants would be recognised.
Another possibility could be to pack the exe with upx tool for instance.
http://upx.sourceforge.net/
It will expand the whole file in memory before run.
And it will save bandwidth.
I release a single executable (.EXE) for a desktop program using Delphi 2009. I have no external DLLs or resources that I need for the program to run.
I use two components: LMD Innovative's ELPack and Sergey Tkachenko's TRichView that are compiled into my executable.
When I build my production version, using the "Release" build configuration, the executable file produced is 13,533 KB.
Prior to using Delphi 2009, I was using Delphi 4. The executable it produced was only 2,671 KB while incorporating the same two components and basically having the same code as my current version.
I do understand that Delphi 2009 is completely Unicode (which is the main reason why I upgraded), and being Unicode can cause up to a doubling of size. But this is about 5 times larger.
Is there a reason why my executable has to remain 5 times larger? Or are there some simple ways to cut down a significant chunk of the executable size?
Please note. Some people are answering with ways to compress the Delphi EXE. That is not what I am trying to do. I am trying to simply see why so much space is being used to remove what might not be necessary. If that is done, compression can still be done afterwards if so desired.
It really doesn't matter how big or small the executable is once it is installed. It is for downloading purposes and to minimize server load and download times that you want to compress it. I prefer to use Inno Setup and compress the program inside the install routine itself. Then when it is installed, it is expanded to full size. That both prevents possible detection as a virus and eliminates the extra startup time needed to uncompress the program in memory. Also I code sign both my executable and my install routine and some compression techniques are incompatible with that.
For more info about compressing, see the StackOverflow question: Delphi EXE compressor?
ldsandon asked me to provide exactly what options I'm using, so here they are:
(source: beholdgenealogy.com)
(source: beholdgenealogy.com)
When moving from Delphi 7 to Delphi 2010., our .exe's grew for example from 16 megs to 35 megs.
I asked a question similar to yours on the Embarcadero forum a few weeks ago. (link) In my OP, I listed a series of links on this subject that you might find helpful.
We tried using UPX to compress our .exe's. Letting it work for hours significantly reduced our .exe, but we probably won't use it in production for these reasons:
We have quite a few .exe's and don't want to wait 1/2-day on each build. (It's possible that we could find a non-brute force set of parameters to UPX that would reduce this...)
Although the size of the .exe is reduced, our shippable was not, because our installer (not surprisingly) is unable squeeze much more compression out of the already compressed file... whereas it was able to reduce the original 16 meg .exe down to 8 megs.
I've read some reports that at some time (rarely, but not never), UPX exe's triggered various anti-virus programs to report the application contained a virus. (I don't recall the date, site, or details of where I saw this, so it's a bit unfair of me to report it here.) But, we are so adverse to taking a risk of that even possibility happening, that UPX is off the table...
The link on the Embarcadero forum also includes a link to another SO thread on this topic.
I continue to be surprised and disappointed at the code bloat we found when moving to Delphi 2010. As Nick notes, 2X for Unicode is quite excessive.
However, the bloat is a relatively minor trade-off when moving to D2010, because, IMO, D2010 is such a terrific upgrade in so many other ways. But, it does mean that we'll probably have to move to shipping 2 CDs rather than one. I'm not looking forward to seeing the reaction to this from our organization...
Without seeing the actual settings that your "Release" build configuration uses explaining this increase in size requires a great deal of speculation.
Beyond some perhaps unlikely factors resulting in a vast increase in the amount of code being "dragged in" even though it isn't used, that magnitude of increase would most easily be explained by the inclusion of debug information.
I would check your compiler and linker settings for:
Debug Information (compiler setting)
TD32 info (linker)
Remote debug info (linker)
Compare these settings in your Delphi 2009 project with the equivalents in Delphi 4.
Factor out the expected 2X increase from Unicode and you end up with a 2.5X increase unaccounted for. This makes sense considering how many versions you've skipped. A lot's been added to the VCL and RTL since Delphi 4, and not all of it is stuff that can be easily smartlinked out, even if you never use it. Depending on how many units you're using, you could be hauling in quite a bit of extra baggage.
Allen Bauer and the compiler team added a new feature into D2010 to help reduce this, but apparently they're treading cautiously and didn't use it in as many places as they could have. Hopefully we'll see more cruft reduction in 2011 and subsequent releases.
I will add my few words.
Linker can remove unused procedures and functions only if it can follow the code hierarchy. The nightmare list for linker listed below:
Message-driven code, the sad news is that this code can't be removed whatsoever, that's why Delphi blank project size continues growing from version to version. Every new windows message (WM_TOUCH for example as long as I know introduced recently) creates procedure call hierarchy that can't be removed (even if you don't have plan to use Touch API at all). This is because every case WM_: fragment is something linker can't decide whether it will be used or not.
Code and data structures accessed from the begin end, initialization, finalization secions of the units. Here you have some control, remove unnecessary calls or object creation. Even if you create objects on demand and only free them in finalization section, make it carefully
Use "upx - compress or expand executable files" # http://upx.sourceforge.net
If you go to tools/configure tools, and set it up like this, you can compress the executable that you're working on easily via a menu item in the IDE.
Another way is to have a look to 'what unit increase the size ?'.
To do this, I use the JCL 'Project Analyser IDE', integrated in the IDE with the JCL/JVCL installation, it show you all the units with their respective size. You can export it in text file.
If you do it with the 2 environnements (D4 & D2009) you will have a lot of pertinent informations.
I've done some tests to see the difference between D2007 and D2010, because we are upgrading to D2010. I've tested a medium sized management GUI application, with about 60 forms (grids with detail forms, frames, etc). We're using TMS components + Remobjects.
D2007:
"normal" compilation: 18.8mb
with debug dcu's: 18.8mb (same size!)
D2010
normal: 23.9
debug dcu's: 48.8mb (!)
So using debug dcu's doubles our exe size...
Test with our business service (no big dfm's):
D2007: 12.3mb
D2010: 17.1mb
So yes, D2010 increases the exe (a bit), but this is not a problem for my customer.
Edit: some information about compiled size:
D2007:
D2010:
So an increase of code size, but a more than doubling of the data!
If you don't want to use an exe compressor then you should give StripReloc a try.
Check format of your dfm-s. They must be in binary format if you want to make your exe smaller.
1) You are generating a detailed map file, and because you've set "used debug dcus" it will also contains symbols for the RTL/VCL units. If it is used by an exception handling systems to generate call stacks and the like, it could be added to the executable. And if not compressed somehow, it could make your .exe size pretty large.
2) Using debug dcus will also make your .exe somewhat larger because usually they are compiled without optimization and debug options set, and they will make also your code slower. They shouldn't be used in a release version.
3) Debug information should add debig info only to the unit and not to the executable, although it is required IIRC to generate the map file.
Since D2010 adds extended RTTI, and RTTI is a notorious factor in increasing exe size, it would be interesting to see how big D2009 binaries are for that application.
If D2009 binaries are significantly smaller, it is not Unicode etc. For my own binaries, I only have a 30% increase or so going from D7 to D2009.
It has been stated earlier that using an executable compresser reduces the size of the exe but not of the install package. However, if you want a good compressor then try ASPack.
#Tom1952: ASPack is pretty fast, just a few seconds to compress a file
Also you can change the Icon. Icon in newest delphi IDE (ie XE3) is Vista/7 compatible and contains all sizes (up to 256x256 as far as I know). So you can reduce exe file size with changing the Icon.
The standard units in you newer delphi may contain more strings and constants such as error strings, that is included even if you disable debug information. Check your uses.
Don't have much of a somution besides not using a specific unit, or removing unneeded data from it.
(My experiences are with Delphi 5)
For Delphi 10.3 Rio with default setiings:
Step 1: Switch from Debug to Release in "Projects" window. This reduced my exe file from 22 MB to 5 MB !
Step 2: Use an exe compresor like ASPack. It further reduced my exe file to 1.3 MB. Unbelievable, isn't it ? :)
Uncheck debug information in project options.
If embarcadero can't provide any solution or explanation!!! I think the solution is simple: don't stuck only with Delphi there is a lot of programming languages, every one is limited only by programmer imagination.