Board index » cppbuilder » Access violation in linker (again)

Access violation in linker (again)


2004-07-06 12:08:23 AM
cppbuilder108
OK, back to the checklist:
I am getting the following every time I try to build my current project.
"[Linker Error] Fatal: Access violation. Link terminated."
I have done the usual things -
Check using latest patch (4)
Check .tds file is small (around 30Mb)
Remove every trace of a generated file and perform a clean build of
all libraries and the executable, incrememental linking disabled.
I have cleaned out all other linker warnings (duplicate symbols from
multiple instantiations of same template) although I have not known
these to be a problem anyway.
After tinkering round all day on wild speculation, I have run out of
probably causes.
Can anyone who has found the cause for such problems in the past share
their experience, so I have an idea what to go looking for?
I am happy enough to make a workaround, if I can just narrow down what
is causing the problem in the first place!
AlisdairM(TeamB)
 
 

Re:Access violation in linker (again)

Are you using Pascal based third-party components?
If yes, which ones?
If yes, do you have their sources?
We had that problem in the JCL/JVCL and solved it by getting rid of the
WEAKPACKAGEUNIT directive (see Delphi help, maybe BCB as well for details).
Before that, we also discovered that the order of files in the XML
project source file has an impact on the problem.
Cheers
Olivier Sannier
JVCL Developer
C++ Builder Support Coordinator
 

Re:Access violation in linker (again)

OBones wrote:
Quote
Are you using Pascal based third-party components?
If yes, which ones?
If yes, do you have their sources?
Yes, we are using a small subset of the Orpheus controls.
We compile these as a separate library, and statically link to that
library when building our executables.
I don't think this is the problem, as we make much more extensive use
of Orpheus in our other projects, which are maybe twice the size of
this one. Also, Orpheus code has been stable and untouched (in our
source tree) for almost 2 years now, plenty of time for any issues to
surface!
Quote
We had that problem in the JCL/JVCL and solved it by getting rid of
the WEAKPACKAGEUNIT directive (see Delphi help, maybe BCB as well for
details).
Worth knowing for future reference though, thanks.
Quote
Before that, we also discovered that the order of files in the XML
project source file has an impact on the problem.
Anything specific about the ordering, or did you not get that far?
Last week I split out a static library from an overly large/complex
project. That went fine all week, but something changed on Friday when
I was busy working on something else (always doing 3 things in
parallel) and I'm not sure what broke. Unfortunately, due to the large
scale changes, I did not have a stable build in CVS to refer back to :?
(
[It was only as I committed all changes to CVS the issue hit]
AlisdairM
 

{smallsort}

Re:Access violation in linker (again)

What is the error number?
I get a linker error I think it's LM881 and the only way round it is to
close the project and re-load and re-make the project (after changing a
single file to force the link)
No idea why but it fixes it...
HTH Pete
"Alisdair Meredith (TeamB)"
< XXXX@XXXXX.COM >wrote in message
Quote
OK, back to the checklist:

I am getting the following every time I try to build my current project.
"[Linker Error] Fatal: Access violation. Link terminated."

I have done the usual things -
Check using latest patch (4)
Check .tds file is small (around 30Mb)
Remove every trace of a generated file and perform a clean build of
all libraries and the executable, incrememental linking disabled.

I have cleaned out all other linker warnings (duplicate symbols from
multiple instantiations of same template) although I have not known
these to be a problem anyway.

After tinkering round all day on wild speculation, I have run out of
probably causes.

Can anyone who has found the cause for such problems in the past share
their experience, so I have an idea what to go looking for?

I am happy enough to make a workaround, if I can just narrow down what
is causing the problem in the first place!

AlisdairM(TeamB)
 

Re:Access violation in linker (again)

Pete Fraser wrote:
Quote
What is the error number?
I get a linker error I think it's LM881 and the only way round it is
to close the project and re-load and re-make the project (after
changing a single file to force the link)
No idea why but it fixes it...
What error number? <g>
I'm afraid I copy/pasted the complete message, which is why I am left
pretty clueless right now :? (
AlisdairM(TeamB)
 

Re:Access violation in linker (again)

Not all linker errors have numbers.
Pete Fraser wrote:
Quote
What is the error number?
I get a linker error I think it's LM881 and the only way round it is to
close the project and re-load and re-make the project (after changing a
single file to force the link)
No idea why but it fixes it...
HTH Pete
 

Re:Access violation in linker (again)

Alisdair,
This is a stab in the dark but I got around a different linker problem using this
approach yesterday: If you have a lot of Library paths that are long strings then put
the files on much shorter paths. Avoid spaces and non-alphabetic characters in the
paths too.
Another wild idea: remove some source file (or lib) from the project, change its name
so it will be ordered alphabetically way differently, add back into the project, then
rebuild.
Another wild idea: remove some part of the project and comment out calls to it and
try to rebuild without that part to see if the problem tracks with a particular part
of the program.
Another wild idea: You using precompiled headers? Change the order of the includes in
them.
I really really hate linker errors. If I could get Borland to fix just one thing it
would be linker errors.
Alisdair Meredith (TeamB) wrote:
Quote
OK, back to the checklist:

I am getting the following every time I try to build my current project.
"[Linker Error] Fatal: Access violation. Link terminated."

I have done the usual things -
Check using latest patch (4)
Check .tds file is small (around 30Mb)
Remove every trace of a generated file and perform a clean build of
all libraries and the executable, incrememental linking disabled.

I have cleaned out all other linker warnings (duplicate symbols from
multiple instantiations of same template) although I have not known
these to be a problem anyway.

After tinkering round all day on wild speculation, I have run out of
probably causes.

Can anyone who has found the cause for such problems in the past share
their experience, so I have an idea what to go looking for?

I am happy enough to make a workaround, if I can just narrow down what
is causing the problem in the first place!

AlisdairM(TeamB)
 

Re:Access violation in linker (again)

Another stab in the dark:
There is a patch that should be available from the CBuilder Developers
downloads page soon
www.borland.com/products/downloads/download_cbuilder.html#
which fixes access violations with many (>130) object files. My hunch
is that this is not your issue.
Try exporting to makefile and building from the command line. This
should give you more feedback. If there is no confidential information
in the filenames or variable names in the error messages, you could also
upload the makefile to QC or RAID for Borland QA (me) to look at.
Randall Parker wrote:
Quote
Alisdair,

This is a stab in the dark but I got around a different linker problem
using this approach yesterday: If you have a lot of Library paths that
are long strings then put the files on much shorter paths. Avoid spaces
and non-alphabetic characters in the paths too.

Another wild idea: remove some source file (or lib) from the project,
change its name so it will be ordered alphabetically way differently,
add back into the project, then rebuild.

Another wild idea: remove some part of the project and comment out calls
to it and try to rebuild without that part to see if the problem tracks
with a particular part of the program.

Another wild idea: You using precompiled headers? Change the order of
the includes in them.

 

Re:Access violation in linker (again)

Randall Parker wrote:
Quote
This is a stab in the dark but I got around a different linker
problem using this approach yesterday: If you have a lot of Library
paths that are long strings then put the files on much shorter paths.
Avoid spaces and non-alphabetic characters in the paths too.
Library path are under control, but I had forgotten to check. Thanks
for reminder.
Quote
Another wild idea: remove some source file (or lib) from the project,
change its name so it will be ordered alphabetically way differently,
add back into the project, then rebuild.
Another wild idea: remove some part of the project and comment out
calls to it and try to rebuild without that part to see if the
problem tracks with a particular part of the program.
I've actually removed a minimal subset of around 10 cpps in order to
make a working test project. It would be less for filing a bug report,
but I'm making minimal code changes to test right now, and dependencies
bring dependencies...
Quote
Another wild idea: You using precompiled headers? Change the order of
the includes in them.
Turned them off at an earlier test <g>
Quote
I really really hate linker errors. If I could get Borland to fix
just one thing it would be linker errors.
I hear you!!
AlisdairM(TeamB)
 

Re:Access violation in linker (again)

Robert Ehteshamzadeh (Borland QA) wrote:
Quote
Another stab in the dark:

There is a patch that should be available from the CBuilder Developers
downloads page soon

www.borland.com/products/downloads/download_cbuilder.html#

which fixes access violations with many (>130) object files. My
hunch is that this is not your issue.
BCB patch 5? Great news!!! <g>
And no, this is not the issue as I am now working with a much smaller
test application. 5 minutes restarting the IDE for the old project
after each compile was killing me!!
Quote
Try exporting to makefile and building from the command line.
Tried that, but could not get a valid mak out of bpr2mak.
Unfortunately I'm an IDE junkie, so don't know the make file format to
fix this up myself.
Quote
This should give you more feedback. If there is no confidential
information in the filenames or variable names in the error messages,
you could also upload the makefile to QC or RAID for Borland QA (me)
to look at.
If I don't get anywhere by lunch time, you can be sure I will do this
<g>Will take a little while to strip out the final dependencies
though, so the test case is a reasonable size.
Also, this code uses the Loki factory library. Can I assume that will
be available in the test environment, or should I bundle a copy of the
required headers with the project?
AlisdairM(TeamB)
 

Re:Access violation in linker (again)

"Alisdair Meredith (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
Randall Parker wrote:


>Another wild idea: remove some source file (or lib) from the project,
>change its name so it will be ordered alphabetically way differently,
>add back into the project, then rebuild.

>Another wild idea: remove some part of the project and comment out
>calls to it and try to rebuild without that part to see if the
>problem tracks with a particular part of the program.
What I have done in the past is to open the bpr in a text editor,
go to the files section, select it and sort in reverse order. If the
problem goes away, put it back and start moving filenames
to find the actual culprit. In many cases it's due to the broken
lookup algorithm (first 8 chars or the filename are duplicated
and the linker can't determine that they're different) but just
changing the order of the files seems to help. So much for
a multipass linker <g>
 

Re:Access violation in linker (again)

Robert Ehteshamzadeh (Borland QA) wrote:
Quote
If there is no confidential
information in the filenames or variable names in the error messages,
you could also upload the makefile to QC or RAID for Borland QA (me)
to look at.
Got it! I'll see what I can do about sending you a reproducible test
case.
In the end it is a namespace bug.
I use the Loki factory library to register creator functions in a map.
Each creator function returns a pointer to a new instance of the base
class supported by that factory.
If the base class is in the namespace for our project (ngis::voyager)
then the linker gives an access violation. If we move the base class
back into the global namespace, it is fixed.
I have been cleaning up the code in this project I inherited.
(Unfortunately I can't complain too much, it is my design, just not my
implementation until now ;? )
One of the first clean-ups I am looking at is clearer naming, and using
the company namespaces seemed to make sense...
Not yet sure if it is specifically our namespace (just as
std::make_pair gives the compiler problem for using declarations) or it
applies to all namespaces, or even just nested namespaces.
Will look into this more tonight (at home) with a factory for
std::exception. Should be a small test case if it shows the bug!
Now time to remove all those pages and pages of test code, comments and
other hacks from 2 days investigation...
AlisdairM(TeamB)
 

Re:Access violation in linker (again)

Alisdair Meredith (TeamB) wrote:
Quote
One of the first clean-ups I am looking at is clearer naming, and
using the company namespaces seemed to make sense...
Get thee behind me, Alisdair :)
The subject comes up here occasionally for our main DLL but at 223
units and with code dating back to 1991 it rarely goes much beyond the
proposal stage in meetings. Possibly that's because me and a colleague
go a funny colour and have to have a window opened...
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Access violation in linker (again)

Andrue Cope [TeamB] wrote:
Quote
Get thee behind me, Alisdair :)

The subject comes up here occasionally for our main DLL but at 223
units and with code dating back to 1991 it rarely goes much beyond the
proposal stage in meetings. Possibly that's because me and a colleague
go a funny colour and have to have a window opened...
A quick filecount on our main CVS just turned up 1300 .cpp files, is
that what you mean by a unit?
Most of that is namespaced now, although we leave the VCL forms in the
global namespace rather than mess with autogenerated code. That
probably takes around 400 files out the equation.
Yes, most of this is now nicely separated into meaningful namespaces,
and pretty much a solo effort by yours truly :?(
If you really want to do this, it is not hard. Just takes time and
patience. Start using namespaces for new libraries, and slowly roll
the namespaces back into lower layers as time permits. It has taken me
3 years to get to this stage, although most work was done in the first
12 months.
The hard part is getting buy-in, so that everyone thinks to use
namespaces when writing new code (hence some of my maintenance!)
DLLs would be a more interesting problem though, as we keep to a pretty
strict C interface for DLLs, and C does not support namespaces.
However...
We do wrap out DLLs in a much friendlier C++ wrapper class, that hide
the DLL interface headers and does sit in a namespace <g>
I suspect we have rather fewer DLLs than you do though!
AlisdairM
 

Re:Access violation in linker (again)

Alisdair Meredith (TeamB) wrote:
Quote
A quick filecount on our main CVS just turned up 1300 .cpp files, is
that what you mean by a unit?
Pretty much, yeah. Ouch :)
Quote
However...
We do wrap out DLLs in a much friendlier C++ wrapper class, that hide
the DLL interface headers and does sit in a namespace <g>
I spent a week earlier this year swinging the axe on our old, evolved,
DLL API. The number of exported functions dropped from over two hundred
to less than a dozen. All of the real work functions are now accessed
through one of four dispatch mechanisms. Means I can produce a really
/detailed/ audit trail should the need arise :)
Quote
I suspect we have rather fewer DLLs than you do though!
Oh I dunno. We only ship six DLLs (*). Our problem is that some of
those DLLs use each other. Some directly (which means guarding
LoadLibrary/FreeLibrary) and others through callbacks passed in by a
client.
Yesterday I had to debug a minor issue in our DLL. Execution had got
there because:
Another DLL had called it through a callback from another DLL..
..which was being called from the DLL being debugged..
..which was being called through a callback from the EXE..
..in response to a request from that same EXE.
You can get /seriously/ confused in that situation. Kudos to the BCB6
de{*word*81} for not getting confused - I just wish it had a way to tell me
what 'instance' of a DLL it is currently inspecting :-/
(*)Of our own making, that is. We use the Stellant OutsideIn library
(www.inso.com) and that means several hundred DLLs. Oh and they have to
callback to us when they want to read data for a file.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html