2 Linker fatal errors and access violation
Randall Parker
I'm compiling about 250 .cpp files, even more .h files included, and some boost headers. Finally got thru compilation. But the Linker chokes.
The most severe statements from the linker are these 3 errors including an access violation. I also found curious the "unknown heap" warning. What is that about?
Is this the right group for linker problems?
[ILINK32 Error] Fatal: Error detected (LME1511)
[ILINK32 Error] Fatal: Error detected (LME1744)
[ILINK32 Error] Fatal: Access violation. Link terminated.
[ILINK32 Warning] Warning: BSS : 0x00000000 / 0x01001000
[ILINK32 Warning] Warning: CODE : 0x0000e2c1 / 0x00400000
[ILINK32 Warning] Warning: DATA : 0x000ebf1a / 0x00400000
[ILINK32 Warning] Warning: DEBNAM : 0x00053190 / 0x00400000
[ILINK32 Warning] Warning: DEBSYM : 0x0001ef70 / 0x00400000
[ILINK32 Warning] Warning: DEBTYP : 0x000530ba / 0x00400000
[ILINK32 Warning] Warning: Extdef flags : 0x0000006f / 0x00004000
[ILINK32 Warning] Warning: Extdefs : 0x000001bc / 0x00004000
[ILINK32 Warning] Warning: External types : 0x00000160 / 0x00040000
[ILINK32 Warning] Warning: Import symbols : 0x00000000 / 0x00100000
[ILINK32 Warning] Warning: Line number cache : 0x000062be / 0x00060000
[ILINK32 Warning] Warning: OBJ symbols : 0x0000cfcc / 0x00100000
[ILINK32 Warning] Warning: Public GSX : 0x00000e84 / 0x000c0000
[ILINK32 Warning] Warning: Publics : 0x000082a4 / 0x000c0000
[ILINK32 Warning] Warning: SegRelocs : 0x0000eab0 / 0x00400000
[ILINK32 Warning] Warning: StringBlock : 0x00003fce / 0x00400000
[ILINK32 Warning] Warning: Type names : 0x00000ccd / 0x00100000
[ILINK32 Warning] Warning: UNKNOWN : 0x00000006 / 0x00400000
[ILINK32 Warning] Warning: Virdefs : 0x00000e84 / 0x00020000
[ILINK32 Warning] Warning: CODE : 0x00004d93 / 0x00400000
[ILINK32 Warning] Warning: DATA : 0x000ea6ee / 0x00400000
[ILINK32 Warning] Warning: DEBNAM : 0x0001b1e7 / 0x00400000
[ILINK32 Warning] Warning: DEBSYM : 0x0001074b / 0x00400000
[ILINK32 Warning] Warning: DEBTYP : 0x00027dfb / 0x00400000
[ILINK32 Warning] Warning: Extdef flags : 0x00000048 / 0x00004000
[ILINK32 Warning] Warning: Extdefs : 0x00000120 / 0x00004000
[ILINK32 Warning] Warning: Import symbols : 0x00000000 / 0x00100000
[ILINK32 Warning] Warning: Line number cache : 0x0000212a / 0x00060000
[ILINK32 Warning] Warning: OBJ symbols : 0x000061b4 / 0x00100000
[ILINK32 Warning] Warning: Public GSX : 0x0000065c / 0x000c0000
[ILINK32 Warning] Warning: Publics : 0x0000393c / 0x000c0000
[ILINK32 Warning] Warning: SegRelocs : 0x00000f28 / 0x00400000
[ILINK32 Warning] Warning: StringBlock : 0x00001f23 / 0x00400000
[ILINK32 Warning] Warning: Virdefs : 0x0000065c / 0x00020000
[ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ilc: 0x00184000 / 0x03000000
[ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ild: 0x030cc000 / 0x03000000
[ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ilf: 0x0024b000 / 0x03000000
[ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ils: 0x002d2000 / 0x03000000
[ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.tds: 0x00850000 / 0x06000000
[ILINK32 Warning] Warning: unknown heap name : 0x03000000 / 0x03000000
[ILINK32 Error] Fatal: Error detected (LME1511)
[ILINK32 Warning] Warning: BSS : 0x00000000 / 0x01001000
[ILINK32 Warning] Warning: CODE : 0x0000e2c1 / 0x00400000
[ILINK32 Warning] Warning: DATA : 0x000ebf1a / 0x00400000
[ILINK32 Warning] Warning: DEBNAM : 0x00053190 / 0x00400000
[ILINK32 Warning] Warning: DEBSYM : 0x0001ef70 / 0x00400000
[ILINK32 Warning] Warning: DEBTYP : 0x000530ba / 0x00400000
[ILINK32 Warning] Warning: Extdef flags : 0x0000006f / 0x00004000
[ILINK32 Warning] Warning: Extdefs : 0x000001bc / 0x00004000
[ILINK32 Warning] Warning: External types : 0x00000160 / 0x00040000
[ILINK32 Warning] Warning: Import symbols : 0x00000000 / 0x00100000
[ILINK32 Warning] Warning: Line number cache : 0x000062be / 0x00060000
[ILINK32 Warning] Warning: OBJ symbols : 0x0000cfcc / 0x00100000
[ILINK32 Warning] Warning: Public GSX : 0x00000e84 / 0x000c0000
[ILINK32 Warning] Warning: Publics : 0x000082a4 / 0x000c0000
[ILINK32 Warning] Warning: SegRelocs : 0x0000eab0 / 0x00400000
[ILINK32 Warning] Warning: StringBlock : 0x00003fce / 0x00400000
[ILINK32 Warning] Warning: Type names : 0x00000ccd / 0x00100000
[ILINK32 Warning] Warning: UNKNOWN : 0x00000006 / 0x00400000
[ILINK32 Warning] Warning: Virdefs : 0x00000e84 / 0x00020000
[ILINK32 Warning] Warning: CODE : 0x00004d93 / 0x00400000
[ILINK32 Warning] Warning: DATA : 0x000ea6ee / 0x00400000
[ILINK32 Warning] Warning: DEBNAM : 0x0001b1e7 / 0x00400000
[ILINK32 Warning] Warning: DEBSYM : 0x0001074b / 0x00400000
[ILINK32 Warning] Warning: DEBTYP : 0x00027dfb / 0x00400000
[ILINK32 Warning] Warning: Extdef flags : 0x00000048 / 0x00004000
[ILINK32 Warning] Warning: Extdefs : 0x00000120 / 0x00004000
[ILINK32 Warning] Warning: Import symbols : 0x00000000 / 0x00100000
[ILINK32 Warning] Warning: Line number cache : 0x0000212a / 0x00060000
[ILINK32 Warning] Warning: OBJ symbols : 0x000061b4 / 0x00100000
[ILINK32 Warning] Warning: Public GSX : 0x0000065c / 0x000c0000
[ILINK32 Warning] Warning: Publics : 0x0000393c / 0x000c0000
[ILINK32 Warning] Warning: SegRelocs : 0x00000f28 / 0x00400000
[ILINK32 Warning] Warning: StringBlock : 0x00001f23 / 0x00400000
[ILINK32 Warning] Warning: Virdefs : 0x0000065c / 0x00020000
[ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ilc: 0x00184000 / 0x03000000
[ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ild: 0x030cc000 / 0x03000000
[ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ilf: 0x0024b000 / 0x03000000
[ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ils: 0x002d2000 / 0x03000000
[ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.tds: 0x00850000 / 0x06000000
[ILINK32 Warning] Warning: unknown heap name : 0x03000000 / 0x03000000
[ILINK32 Error] Fatal: Error detected (LME1744)
[ILINK32 Error] Fatal: Access violation. Link terminated.
Jason Cipriani
news:47e93cc7$1...@newsgroups.borland.com...
>
> I'm compiling about 250 .cpp files, even more .h files included, and some
> boost headers. Finally got thru compilation. But the Linker chokes.
>
> The most severe statements from the linker are these 3 errors including an
> access violation. I also found curious the "unknown heap" warning. What is
> that about?
Out of curiosity, if you go to your project build settings, in Linker ->
Linking, and:
- Disable incremental link.
- Clear state before linking.
Then Clean your project, then Build it. Does it link?
> Is this the right group for linker problems?
You will probably find knowledgeable people here. There is also
borland.public.cppbuilder.commandlinetools; despite being inactive the
response times on the messages are still pretty quick, but I suspect that
most of the people that frequent that newsgroup are here as well.
Jason
dhoke
"Randall Parker" <nos...@nospam.net> wrote in message
news:47e93cc7$1...@newsgroups.borland.com...
>
>
>
kinda, sorta, because that's probably where most people are using the linker
from...
Interestingly, I have on at least one occasion gotten differing results
using the command line vs the IDE - but in that particular situation neither
of the results was good.
Randall Parker
"Jason Cipriani" <jason.c...@nospam-gmail.com> wrote:
>Out of curiosity, if you go to your project build settings, in Linker ->
>Linking, and:
>
>- Disable incremental link.
Already disabled.
>- Clear state before linking.
Not sure what you mean by "Clear state".
>Then Clean your project, then Build it. Does it link?
Did the Clean. Did the Build. Still have the same 3 linker errors.
I have no idea how to investigate this one.
I can't open a problem report with Borland this week because I need to wait for manager high enough up in the hierarchy to approve releasing the source code to Borland/CodeGear to investigate. Back to MS VS and gcc for now.
Jason Cipriani
> "Jason Cipriani" <jason.c...@nospam-gmail.com> wrote:
>>- Clear state before linking.
>
> Not sure what you mean by "Clear state".
By "clear state before linking" I mean the option with the caption "clear
state before linking" on that page (for information about exactly what it
does, press the Help button, located at the bottom right corner of that same
window). It's in the Advanced pane, right underneath the "Verbose" option.
Check it. Although doing the Clean first may already clear linker state
files... and since that didn't help you I doubt this option will either.
Do you get any information by turning the linker's Verbose option on?
Does it happen with all of your build configurations (both with and without
debugging info)?
Jason
Randall Parker
"Jason Cipriani" <jason.c...@nospam-gmail.com> wrote:
>
>"Randall Parker" <nos...@nospam.net> wrote in message
>news:47e9568e$1...@newsgroups.borland.com...
>> "Jason Cipriani" <jason.c...@nospam-gmail.com> wrote:
>>>- Clear state before linking.
>>
>> Not sure what you mean by "Clear state".
>
>By "clear state before linking" I mean the option with the
>caption "clear state before linking" on that page
Okay, I clicked that on and it didn't help.
>Do you get any information by turning the linker's Verbose option on?
I tried that too. Strangely, I did not get any extra text written out with that checked. Still failed with same errors.
>Does it happen with all of your build configurations (both
>with and without debugging info)?
Same errors when built without debug info.
dhoke
errors. With some effort (probably some multiple of hours up to a day) you
may be able to create a link set that does not require source to reproduce
the problem.
The first step would be to see if you can reproduce the problem linking from
the command line.
Then if the problem does reproduce (I've had an instance where different
problems occurred using bds2006 IDE vs command line), you should be able to
bundle up the object set and provide it to borland. You might inquire of
David Dean of CodeGear (who sometimes posts here) whether they are
interested in such a submission or not, and if so I expect he will tell you
where/how to provide it.
Hopefully the referenced post above contains enough details regarding how to
duplicate a command line link attempt, and how I've gone about gathering up
a reproduction linkset, that you can do likewise if you wish.
"Randall Parker" <nos...@nospam.net> wrote in message
news:47e9568e$1...@newsgroups.borland.com...
Randall Parker
> It may not be necessary to provide them with source to reproduce linker
> errors. With some effort (probably some multiple of hours up to a day) you
> may be able to create a link set that does not require source to reproduce
> the problem.
>
> see:
> http://groups.google.com/group/borland.public.cppbuilder.ide/browse_thread/thread/c247867a32450514/1ebe5b8cb4f9d0cd?hl=en&lnk=st&q=dhoke+command+line+link+resp+copy#1ebe5b8cb4f9d0cd
Were you able to get a fix out of Borland for a linker problem you
submitted to them?
If so, how long did it take to get the fix?
vavan
<dhoke....@east-shore.com> wrote:
>It may not be necessary to provide them with source to reproduce linker
>errors. With some effort (probably some multiple of hours up to a day) you
>may be able to create a link set that does not require source to reproduce
>the problem.
when I had some problems with ulink in the past all I needed was to
send to author all required object/libs/resources etc. (using response
file), he never asked me to send any sources. nothing complex at all
p.s. still wonder why people here still bother with ilink after all
those years of troubles. I don't think that cg will ever be able to
produce decent linker. I finally switched to another linker couple of
years ago, got incredible boost in productivity and never looked back
since then
--
Vladimir Ulchenko aka vavan
Leo Siefert
>I'm compiling about 250 .cpp files, even more .h files included, and
>some boost headers. Finally got thru compilation. But the Linker
>chokes.
There have been a number of QC reports on this type of linker problem,
mostly with the filers unable to supply a demo project and saying that
it happens only in very large complex projects.
So I spent some time banging together a very large project with benign
and repetitive code, nothing third party and no external libraries -
just a lot of forms and units, and got the same two errors you show. I
attached the project to this report and it is now open:
Report No: 32020 Status: Open
Fatal Linker Error LME1598
http://qc.codegear.com/wc/qcmain.aspx?d=32020
QCWIN:Defect_No=32020
I am hoping that this will be addressed quickly by CG now that they
have a good reproducible case with no third-party dependencies.
You and anyone else seeing these problems may consider voting on the
report. Remember, you can add up to 10 per report.
That being said, with the number of reports of fatal linker errors on
large projects, it is entirely possible that there are also other
sources of the problem, but a fix for this should at least help to
clarify any other issues.
- Leo
Randall Parker
vavan <Vavan...@ThisSantel.ru> wrote:
>p.s. still wonder why people here still bother with ilink after
>all those years of troubles. I don't think that cg will ever be
>able to produce decent linker. I finally switched to another
>linker couple of years ago, got incredible boost in productivity
>and never looked back since then
Can one use an alternative linker when doing builds in CB?
If so, where can one get this linker?
dhoke
"Randall Parker" <"STOPfutureEVILpundit[at]EVILfuturePOXpunditSPAM[dot]com">
wrote in message news:47e9cdf9$1...@newsgroups.borland.com...
>> see:
>> http://groups.google.com/group/borland.public.cppbuilder.ide/browse_thread/thread/c247867a32450514/1ebe5b8cb4f9d0cd?hl=en&lnk=st&q=dhoke+command+line+link+resp+copy#1ebe5b8cb4f9d0cd
>
> Were you able to get a fix out of Borland for a linker problem you
> submitted to them?
Not yet, but I think a fix, or some change, will be occurring when they
finally figure out root cause. Whether my shop benefits from it (still @
bds2006) or only those of you who are beyond me, remains to be seen. (The
linker seems to be fairly isolated, so I suspect they can release it for my
version and maybe even older, with little effort, but, don't know.)
And I wouldn't be too surprised if your problem disappears when they get
what I've provided addressed, but that is a pretty subjective assessment...
(based on my problem(s) having three different manifestations, all suspected
by me to be from same root cause.)
>
> If so, how long did it take to get the fix?
As indicated still waiting...
In case your interested in the history...
I believe continues here (although thus far B/CG would probably believe them
to be different issues):
http://groups.google.com/group/borland.public.cppbuilder.ide/browse_thread/thread/d6320e804aacd03d/80c1c94d3ab8546f?lnk=st&q=bds2006+ide+project+same+path+problem#80c1c94d3ab8546f
with a linkset involving the unresolved externals provided to them
(mentioned in that thread.)
However due to "incorrect" pragma usage, the linkset was ultimately deemed
"polluted" (my word), with the incorrect pragma usage stated by B/CG as
causing the unresolved externals internally (still a linker issue I'd say) -
I disagreed, since renaming the paths would cause the problem to
appear/disappear, and the incorrect pragma usage existed in both cases. (I
quote "incorrect" above because I think any pragma or general language
feature should be useable without causing the toolset problems.)
So, yet later, after other people were complaining of link problems and
apparently failing to obtain linksets reproducing the problem, I returned to
my original issue (bad executable), and got different, though still bad
results:
http://groups.google.com/group/borland.public.cppbuilder.ide/browse_thread/thread/ce8737ee9b7fbe53/9b9ee76fc490c89d?lnk=st&q=dhoke+bds2006+link+unsupported+resource#9b9ee76fc490c89d
for which I was able to find no useful solution (all search results I read
regarding that error did not seem to apply to my situation).
So I turned to another project in the shop (not mine) which more recently
had been seen to exhibit the good/bad executable scenario, and with that
(knowing the version control revisions involved) succeeded in producing a
linkset which exhibited the problem. I submitted that, I think around
middle of January 2008. Unfortunately, I did a sloppy job assembling it
(missed pieces), and in the last week (today is Mar 26, 2008) was informed
of this.
I have since re-assembled that linkset and re-submitted, and have been
informed that it does exhibit the behaviour for them, that I have reported.
What will come of this, remains to be seen.
Larry Griffiths
Did you just from BDS2006 to BDS2007?
If you converted, did you create brand new projects and add the units to
them?
Larry Griffiths
Randall Parker
CodeGear™ C++Builder® 2007 R2 Version 11.0.2902.10471, has December 2007 Update and February 2008 Help Update.
>Did you just from BDS2006 to BDS2007?
No, this was a fresh install on a machine that also was a fresh install of XP SP2.
>If you converted, did you create brand new projects and add
>the units to them?
I'm migrating a project from MS VS 2003 SP1. I added all source files manually (and this tool ought to have an "import directory tree" feature like Visual Slick Edit does). So I don't have any
legacy upgrade issues.
My project has 248 .cpp files and a similar number of .h files. Plus, it uses several pieces of Boost, bringing in lots of big header files with lots of templates.
Larry Griffiths
your project?
Larry
"Randall Parker" <nos...@nospam.net> wrote in message
news:47ea6c72$1...@newsgroups.borland.com...
>
> "Larry Griffiths" <nos...@nowhere.com> wrote:
>>What BDS version are you using?
>
> CodeGearT C++Builder® 2007 R2 Version 11.0.2902.10471, has December 2007
Jason Cipriani
news:47ea7595$1...@newsgroups.borland.com...
> Im not familar with the Boost. How hard would it be to remove Boost from
> your project?
I think I can answer this for him: [Probably] really freakin' hard. <g>
Boost is, in a nutshell, a huge collection of C++ libraries and utilities,
making heavy use of C++ language features like templates, that can make C++
programming a lot more convenient. For example, various types of "smart"
pointers, threading constructs, math utilities, metaprogramming, all sorts
of strange C++ tricks and tools, way too many things to list. It's a huge
collection; check out the list here:
http://www.boost.org/libs/libraries.htm
If you are not familiar with Boost, I highly suggest becoming familiar with
it, especially, in fact, as a good amount of it will be integrated into C++
(as part of std) in the next release of the standard (C++0x).
Jason
Jonathan Benedicto
> Can one use an alternative linker when doing builds in CB?
Yes.
> If so, where can one get this linker?
ftp://ftp.styx.cabel.net/pub/UniLink
You'll have to use a 3rd party integration plugin like one of the following
to use it:
TwineCompile - http://www.jomitech.com/twine.php
bcc32pch - http://andy.jgknet.de/cpp/index.php
Jon
Jason Cipriani
news:1hiku3102559os1cl...@4ax.com...
> Randall Parker wrote:
>
>>I'm compiling about 250 .cpp files, even more .h files included, and
>>some boost headers. Finally got thru compilation. But the Linker
>>chokes.
>
> There have been a number of QC reports on this type of linker problem,
> mostly with the filers unable to supply a demo project and saying that
> it happens only in very large complex projects.
>
> So I spent some time banging together a very large project with benign
> and repetitive code, nothing third party and no external libraries -
> just a lot of forms and units, and got the same two errors you show. I
> attached the project to this report and it is now open:
Guys,
Good news I think. I actually came here to report that I've also managed to
construct a simple project with no external dependencies that can
consistently crash the linker with the same exact errors Randall is getting
(LM1511 followed by LM1744, and an access violation). Leo, what do you want
me to do with it? I could open a new QC, as yours deals with an error
LME1598, not LM1511/LM1744. I think it is a very good test case.
The project consists of 700 generated units, each unit containing 5 exported
functions, each of which does absolutely nothing but calls one random
function from each of the 700 units. It's current form is a single-threaded
console application with no VCL support (although the RTL that you use, and
whether or not VCL support is enabled, has no effect). It compiles quickly,
and crashes the linker without fail. Other things that I've tried:
* 1000 units, 50 functions: linker doesn't crash, but fails with error:
[ILINK32 Error] Fatal: Exceeded memory limit for block Extdefs in module
Unit10.cpp
* 700 units, 20 functions: same Extdefs error.
* 700 units, 5 functions: crashes linker
* 700 units, 1 function: links OK.
* 1000 units, 50 functions that do *not* call functions from other units,
but call OutputDebugString instead: links OK
I have *no* idea if the Extdefs memory limit exceeded error (note it was a
graceful failure with a proper error) is related; I do know this:
* There is some amount of complexity that doesn't cause that linker error
but does crash the linker (e.g. 700 units, 5 functions each).
* It is *not* related to the sheer number of .obj files, as 1000 units with
50 functions each that did not call functions in the other units did not
have a problem, the "web" of references was required to crash the linker.
For now, I have uploaded this project (700 units, 5 functions each) here:
http://www.sendspace.com/file/hg58ja
Along with the code used to generate it, if anybody wants to try it out.
WinRAR should be able to handle .tar.bz2. Sorry, had to use sendspace, it's
only 1.4MB but b.p.attachments has a 1MB limit.
Jason
P.S. The test with 1000 units and 50 functions each totally wasn't worth it
<g> It ended up taking 15-20 minutes to compile, with 1 GB (!) of source
code (each file had 50000 lines), and 3 GB more of .obj files. The 700x5
version is considerably smaller and compiles in under 30 seconds.
Jason Cipriani
news:47ea840a$1...@newsgroups.borland.com...
> * 1000 units, 50 functions that do *not* call functions from other units,
> but call OutputDebugString instead: links OK
Note that in this case, I did have a single unit that made a call to all
50000 functions, just to make sure the references were used. The linker did
not have a problem with this.
Alex Bakaev [TeamB]
[snip]
> For now, I have uploaded this project (700 units, 5 functions each) here:
Thanks for the effort!
Jason Cipriani
news:47ea840a$1...@newsgroups.borland.com...
> LM1511/LM1744. I think it is a very good test case.
Oops, I guess 32020 does deal with those errors, at least the steps to
reproduce do. But... at least this one compiles in 30 seconds and not "over
an hour"! :-)
Jason
Randall Parker
"Jason Cipriani" <jason.c...@nospam-gmail.com> wrote:
>Guys,
>
>Good news I think. I actually came here to report that I've
>also managed to construct a simple project with no external
>dependencies that can consistently crash the linker with the
>same exact errors Randall is getting (LM1511 followed by
>LM1744, and an access violation). Leo, what do you want
>me to do with it? I could open a new QC, as yours deals
>with an error LME1598, not LM1511/LM1744. I think it is
>a very good test case.
Thanks very much for doing this.
>For now, I have uploaded this project (700 units, 5 functions each) here:
>
>http://www.sendspace.com/file/hg58ja
>
>Along with the code used to generate it, if anybody wants to try it out.
I also found a QC entry that reports this same sequence of LM1511,
LM1744, access violation:
Alex Bakaev [TeamB]
> Oops, I guess 32020 does deal with those errors, at least the steps to
> reproduce do. But... at least this one compiles in 30 seconds and not "over
> an hour"! :-)
>
If only we didn't have to scroll through the unneeded quoted text for 30
seconds! <g>
[big snip]
Jason Cipriani
news:47ea95b0$1...@newsgroups.borland.com...
Well... do it while you're waiting for the code to compile. And give me some
credit, at least I marked the end of the message part with my name!
(Although I have to admit I'm kind of prone to PS's).
Jason
>
>
>
> [big snip]
P.S. :-)
Leo Siefert
>Im not familar with the Boost. How hard
>would it be to remove Boost from your project?
I don't think the problem is either BOOST or upgrading a project. Both
Jason and I were able to create projects entirely in RAD Studio that
show the same errors. The linker cannot handle large projects.
- Leo
Leo Siefert
>I could open a new QC, as yours deals with an error
>LME1598, not LM1511/LM1744. I think it is a very good test case.
If you look at the report you will see that it was originally filed
for LME1598 (and not by me) and with no test case. The test case I
attached generates 1511 and 1744 with a similar stack trace. Since the
report was filed against an earlier version, I was guessing that the
actual error number(s) generated were less important than getting a
test case together that crashes the linker with the "unknown heap
name" diagnostic.
>The project consists of 700 generated...
Definitely hold onto the project as a basis for future test cases, but
it looks like you are producing the same linker error that my project
produces.
>* 1000 units, 50 functions: linker doesn't crash, but fails with error:
>[ILINK32 Error] Fatal: Exceeded memory limit for block Extdefs in module
>Unit10.cpp
I have seen grumbling in internal report comments about some things
just exhausting memory available to the linker - so there may be
similar reports (I did not just now look). If there is not a similar
report and if you same code can be linked without trouble using one of
the alternative linkers, then that might make a good report to show
that this is indeed a problem.
>have a problem, the "web" of references was required to crash the linker.
Hmm. My project has no "web of references", but may have more code
than yours. It is not simply the number of units. Some users are
convinced that the tds file size is important, but my project does not
grow it to the threshold that had been suggested - it remains quite
small.
There may well be more than one issue with the same symptom. I'd like
to see your entire array of different projects on a report filed on
the extdefs error and referencing 32020 as possibly related. Just
checked and there are no QC or RAID reports showing the extdefs error
that I can find - just 4 with it showing in a stack trace.
Not sure if QC can handle such an attachment, but we can always get
the code to CodeGear by other means.
>For now, I have uploaded this project (700 units, 5 functions each) here:
>
>http://www.sendspace.com/file/hg58ja
Thanks.
>The test with 1000 units and 50 functions each totally wasn't worth it
Ok, so no need to send that to CG.
Thanks for the effort. There has bee a fair share of grumbling about
linker errors and it is good to have test cases that expose them
reliably.
- Leo
Johannes Weinert
as you are using Thunderbird you could try QuoteCollapse
<http://quotecollapse.mozdev.org/>. And if you are dealing with nested
quotes "Quote Colors" <http://quotecolors.mozdev.org/> will be your
friend :-). You can use both simultaneously, of course.
Regards
Hans
Larry Griffiths
creating more projects in our project group to alleviate the problem. :)
"Leo Siefert" <lIHATESP...@senate.michigan.gov> wrote in message
news:ga3nu39sn1p21dbek...@4ax.com...
Alex Bakaev [TeamB]
> as you are using Thunderbird you could try QuoteCollapse
[snip]
Thanks for the pointers :) Now, what other poor souls should use? :)
Jason Cipriani
> [snip]
Did you try your tests with incremental linking enabled or disabled? When I
disable it (my default settings), I get the errors in the IDE; but when I
enable it, I actually get a real crash with a Windows standard crash dialog
(the one with Debug, Send Report, etc). Although I am consistently unable to
attach VS to the crashed linker, it always hangs for some reason.
Also, do you know what part of the linking the .ILF file is for? There are 2
lines in the error message (the one I get) that stand out at me:
[ILINK32 Warning] Warning: C:/.../Debug/Project3.ilf: 0x03009000 /
0x03000000
[ILINK32 Warning] Warning: unknown heap name : 0x03000000 / 0x03000000
The reason these two lines stand out is that they are the only two lines
where the first number is >= the second number; I'm assuming it's some kind
of report of sizes of somethings and limits on the size of the somethings.
Jason
Jason Cipriani
> [ILINK32 Warning] Warning: C:/.../Debug/Project3.ilf: 0x03009000 /
> 0x03000000
> [ILINK32 Warning] Warning: unknown heap name : 0x03000000 / 0x03000000
Well, now that I look closer, the error in the OP had it with the .ILD file:
[ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ild:
0x030cc000 / 0x03000000
The original error in that QC report didn't have it with any of those files;
but on the other hand that was a different error number.
Everybody has the "unknown heap name".
Oh well maybe there's nothing important about the filenames in the messages
after all.
Jason
Leo Siefert
>Did you try your tests with incremental linking enabled or disabled?
Disabled. The first suggestion for linker problems has always be
"disable incremental linking", so I figured a test case with it
disabled made more sense.
>Also, do you know what part of the linking the .ILF file is for?
Not really, but "incremental link file" comes quickly to mind. Could
be one of the files the linker saves to help speed up linking when it
is incremental.
>[ILINK32 Warning] Warning: unknown heap name : 0x03000000 / 0x03000000
Most of the reports I have seen have shown this particular line. The
diagnostic is also rather ominous and it is often right after or right
before the LME error,
- Leo
Dev Support
This is a great thread since I am using BCB5 (I know you're laughing at
BCB5. I have upgraded to BCB 2007 but the porting of this project is just
too large of a task right now) and been getting the:
"[LINK32 Error] Fatal: Access violation. Link terminated." error in a
project that has 33 forms and 82 units.
I can share some interesting findings:
BCB5 on XP laptop with 512MB RAM got this error. I could sometimes get out
and restart the IDE and would work. Also, sometimes I could simply do a
build again and it would work AND sometimes it would take a reboot to make
the error go away.
A memory upgrade to this laptop (2G) made the error go away and I have not
seen it since the upgrade on the laptop!
BCB5 on W2K Desktop with 512MB RAM got this error.
Upgrading this memory today to find results.
I only mention this since I did see some talk of the linker eating up memory
and that maybe this is related. I realize that maybe the memory is only
covering the linker problem with extra memory but hey, if it works then
don't fix it, right?
Thank you
Marshall
"Randall Parker" <nos...@nospam.net> wrote in message
news:47e93cc7$1...@newsgroups.borland.com...
>
> I'm compiling about 250 .cpp files, even more .h files included, and some
boost headers. Finally got thru compilation. But the Linker chokes.
>
> The most severe statements from the linker are these 3 errors including an
access violation. I also found curious the "unknown heap" warning. What is
that about?
>
> Is this the right group for linker problems?
>
> [ILINK32 Error] Fatal: Error detected (LME1511)
>
> [ILINK32 Error] Fatal: Error detected (LME1744)
> [ILINK32 Error] Fatal: Access violation. Link terminated.
>
> [ILINK32 Warning] Warning: BSS : 0x00000000 / 0x01001000
> [ILINK32 Warning] Warning: CODE : 0x0000e2c1 / 0x00400000
> [ILINK32 Warning] Warning: DATA : 0x000ebf1a / 0x00400000
> [ILINK32 Warning] Warning: DEBNAM : 0x00053190 / 0x00400000
> [ILINK32 Warning] Warning: DEBSYM : 0x0001ef70 / 0x00400000
> [ILINK32 Warning] Warning: DEBTYP : 0x000530ba / 0x00400000
> [ILINK32 Warning] Warning: Extdef flags : 0x0000006f / 0x00004000
> [ILINK32 Warning] Warning: Extdefs : 0x000001bc / 0x00004000
> [ILINK32 Warning] Warning: External types : 0x00000160 / 0x00040000
> [ILINK32 Warning] Warning: Import symbols : 0x00000000 / 0x00100000
> [ILINK32 Warning] Warning: Line number cache : 0x000062be / 0x00060000
> [ILINK32 Warning] Warning: OBJ symbols : 0x0000cfcc / 0x00100000
> [ILINK32 Warning] Warning: Public GSX : 0x00000e84 / 0x000c0000
> [ILINK32 Warning] Warning: Publics : 0x000082a4 / 0x000c0000
> [ILINK32 Warning] Warning: SegRelocs : 0x0000eab0 / 0x00400000
> [ILINK32 Warning] Warning: StringBlock : 0x00003fce / 0x00400000
> [ILINK32 Warning] Warning: Type names : 0x00000ccd / 0x00100000
> [ILINK32 Warning] Warning: UNKNOWN : 0x00000006 / 0x00400000
> [ILINK32 Warning] Warning: Virdefs : 0x00000e84 / 0x00020000
> [ILINK32 Warning] Warning: CODE : 0x00004d93 / 0x00400000
> [ILINK32 Warning] Warning: DATA : 0x000ea6ee / 0x00400000
> [ILINK32 Warning] Warning: DEBNAM : 0x0001b1e7 / 0x00400000
> [ILINK32 Warning] Warning: DEBSYM : 0x0001074b / 0x00400000
> [ILINK32 Warning] Warning: DEBTYP : 0x00027dfb / 0x00400000
> [ILINK32 Warning] Warning: Extdef flags : 0x00000048 / 0x00004000
> [ILINK32 Warning] Warning: Extdefs : 0x00000120 / 0x00004000
> [ILINK32 Warning] Warning: Import symbols : 0x00000000 / 0x00100000
> [ILINK32 Warning] Warning: Line number cache : 0x0000212a / 0x00060000
> [ILINK32 Warning] Warning: OBJ symbols : 0x000061b4 / 0x00100000
> [ILINK32 Warning] Warning: Public GSX : 0x0000065c / 0x000c0000
> [ILINK32 Warning] Warning: Publics : 0x0000393c / 0x000c0000
> [ILINK32 Warning] Warning: SegRelocs : 0x00000f28 / 0x00400000
> [ILINK32 Warning] Warning: StringBlock : 0x00001f23 / 0x00400000
> [ILINK32 Warning] Warning: Virdefs : 0x0000065c / 0x00020000
> [ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ilc:
0x00184000 / 0x03000000
> [ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ild:
0x030cc000 / 0x03000000
> [ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ilf:
0x0024b000 / 0x03000000
> [ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ils:
0x002d2000 / 0x03000000
> [ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.tds:
0x00850000 / 0x06000000
> [ILINK32 Warning] Warning: unknown heap name : 0x03000000 / 0x03000000
> [ILINK32 Error] Fatal: Error detected (LME1511)
> [ILINK32 Warning] Warning: BSS : 0x00000000 / 0x01001000
> [ILINK32 Warning] Warning: CODE : 0x0000e2c1 / 0x00400000
> [ILINK32 Warning] Warning: DATA : 0x000ebf1a / 0x00400000
> [ILINK32 Warning] Warning: DEBNAM : 0x00053190 / 0x00400000
> [ILINK32 Warning] Warning: DEBSYM : 0x0001ef70 / 0x00400000
> [ILINK32 Warning] Warning: DEBTYP : 0x000530ba / 0x00400000
> [ILINK32 Warning] Warning: Extdef flags : 0x0000006f / 0x00004000
> [ILINK32 Warning] Warning: Extdefs : 0x000001bc / 0x00004000
> [ILINK32 Warning] Warning: External types : 0x00000160 / 0x00040000
> [ILINK32 Warning] Warning: Import symbols : 0x00000000 / 0x00100000
> [ILINK32 Warning] Warning: Line number cache : 0x000062be / 0x00060000
> [ILINK32 Warning] Warning: OBJ symbols : 0x0000cfcc / 0x00100000
> [ILINK32 Warning] Warning: Public GSX : 0x00000e84 / 0x000c0000
> [ILINK32 Warning] Warning: Publics : 0x000082a4 / 0x000c0000
> [ILINK32 Warning] Warning: SegRelocs : 0x0000eab0 / 0x00400000
> [ILINK32 Warning] Warning: StringBlock : 0x00003fce / 0x00400000
> [ILINK32 Warning] Warning: Type names : 0x00000ccd / 0x00100000
> [ILINK32 Warning] Warning: UNKNOWN : 0x00000006 / 0x00400000
> [ILINK32 Warning] Warning: Virdefs : 0x00000e84 / 0x00020000
> [ILINK32 Warning] Warning: CODE : 0x00004d93 / 0x00400000
> [ILINK32 Warning] Warning: DATA : 0x000ea6ee / 0x00400000
> [ILINK32 Warning] Warning: DEBNAM : 0x0001b1e7 / 0x00400000
> [ILINK32 Warning] Warning: DEBSYM : 0x0001074b / 0x00400000
> [ILINK32 Warning] Warning: DEBTYP : 0x00027dfb / 0x00400000
> [ILINK32 Warning] Warning: Extdef flags : 0x00000048 / 0x00004000
> [ILINK32 Warning] Warning: Extdefs : 0x00000120 / 0x00004000
> [ILINK32 Warning] Warning: Import symbols : 0x00000000 / 0x00100000
> [ILINK32 Warning] Warning: Line number cache : 0x0000212a / 0x00060000
> [ILINK32 Warning] Warning: OBJ symbols : 0x000061b4 / 0x00100000
> [ILINK32 Warning] Warning: Public GSX : 0x0000065c / 0x000c0000
> [ILINK32 Warning] Warning: Publics : 0x0000393c / 0x000c0000
> [ILINK32 Warning] Warning: SegRelocs : 0x00000f28 / 0x00400000
> [ILINK32 Warning] Warning: StringBlock : 0x00001f23 / 0x00400000
> [ILINK32 Warning] Warning: Virdefs : 0x0000065c / 0x00020000
> [ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ilc:
0x00184000 / 0x03000000
> [ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ild:
0x030cc000 / 0x03000000
> [ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ilf:
0x0024b000 / 0x03000000
> [ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.ils:
0x002d2000 / 0x03000000
> [ILINK32 Warning] Warning: Z:/Moe/2008Mar13Files/Debug/BCBVCIMain.tds:
0x00850000 / 0x06000000
> [ILINK32 Warning] Warning: unknown heap name : 0x03000000 / 0x03000000
> [ILINK32 Error] Fatal: Error detected (LME1744)
> [ILINK32 Error] Fatal: Access violation. Link terminated.