Board index » cppbuilder » BCB6 - Linker Error after Adding Class to Project (NTDLL.DLL)

BCB6 - Linker Error after Adding Class to Project (NTDLL.DLL)


2008-06-05 01:02:41 AM
cppbuilder87
Hi,
We're having a hell of a time trying to figure out this linker error.
(Note: There are 2 ways to generate this error
1. Cancel a compile of a class (any class)
2. Running the application after compile)
We've triple checked the source code for any errors, and there are none.
We even deleted out all the code content and left a very basic cpp /.h construct. And still the error. Only removing the entire class does the error go away.
It makes absolutely no sense to us. Here is what the break down looks like through a Error Handling 3rd party tool shows us.
Any help to resolve this would be awesome! Thanks in Advance!
~Heinz
system language : English
system up time : 7 days 20 hours
program up time : 1 hour 5 minutes
processors : 2x Intel(R) Pentium(R) 4 CPU 3.00GHz
physical memory : 212/1015 MB (free/total)
free disk space : (C:) 49.39 GB
display mode : 1280x1024, 32 bit
process id : $1074
allocated memory : 88.72 MB
command line : "C:\Program Files\Borland\CBuilder6\Bin\bcb.exe" /np
executable : bcb.exe
current module : madExcept_.bpl
exec. date/time : 2003-01-30 06:04
version : 6.0.10.166
madExcept version : 3.0b
callstack crc : $7a1015a2, $5b8b2866, $5b8b2866
exception number : 2
exception class : EAccessViolation
exception message : Access violation at address 7C901010 in module 'ntdll.dll'. Read of address 4D6E6975.
main thread ($e60):
7c901010 +00b ntdll.dll RtlEnterCriticalSection
012e3a29 +00c bccide.dll GetImageSizes
00b5a99d +0dd bcbide60.bpl CppComIntf TCompiler.PostCompile
00b5a771 +465 bcbide60.bpl CppComIntf TCompiler.Compile
00b6fb0e +03e bcbide60.bpl CppReg TCompilerAdapter.Compile
00b4992b +027 bcbide60.bpl CppMgr TCppProjectUpdater.DoCompile
00b705d0 +1ec bcbide60.bpl CppReg CompileProject
00b4cb8a +02e bcbide60.bpl CppMgr TCppProjectUpdater.CompileProject
00585c2c +074 coreide60.bpl Modules TWorkspace.CompileContainer
00585c8c +014 coreide60.bpl Modules TWorkspace.CompileActive
00b56c5a +01a bcbide60.bpl CBuilderCmds TCBuilderCommands.ProjectCompileUnitCommandExecute
400387ef +00f rtl60.bpl Classes TBasicAction.Execute
400e71a1 +031 vcl60.bpl Actnlist TContainedAction.Execute
400e7e39 +03d vcl60.bpl Actnlist TCustomAction.Execute
400386c4 +034 rtl60.bpl Classes TBasicActionLink.Execute
4010796d +04d vcl60.bpl Controls TControl.Click
4014319c +000 vcl60.bpl Comctrls TToolButton.Click
40107dda +05e vcl60.bpl Controls TControl.WMLButtonUp
401077ec +188 vcl60.bpl Controls TControl.WndProc
401075bc +024 vcl60.bpl Controls TControl.Perform
4010a79c +078 vcl60.bpl Controls TWinControl.ControlAtPos
401075bc +024 vcl60.bpl Controls TControl.Perform
4010a838 +080 vcl60.bpl Controls TWinControl.IsControlMouseMsg
4010a926 +0da vcl60.bpl Controls TWinControl.WndProc
4014735d +231 vcl60.bpl Comctrls TToolBar.WndProc
4010a620 +02c vcl60.bpl Controls TWinControl.MainWndProc
40039478 +014 rtl60.bpl Classes StdWndProc
7e4196c2 +00a user32.dll DispatchMessageA
400f582f +083 vcl60.bpl Forms TApplication.ProcessMessage
400f5866 +00a vcl60.bpl Forms TApplication.HandleMessage
400f5a86 +096 vcl60.bpl Forms TApplication.Run
 
 

Re:BCB6 - Linker Error after Adding Class to Project (NTDLL.DLL)

Please Disregard, we found the problem.
Apparently the Borland Project when adding classes doesn't support long file paths / file names.
I don't know what its limitation is, but this is what one of our guys did to test
C:\ = works.
C:\Test = works.
C:\Testtttt\Tessssssssssssssssssst\JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ\IMMMMMMMMMMMMMMMMLONNNNNNNNNNNNNNNG = fails - ntdll.dll error.
Shame on Borland!
~Heinz
 

Re:BCB6 - Linker Error after Adding Class to Project (NTDLL.DLL)

Heinz Ketchup wrote:
Quote
Apparently the Borland Project when adding
classes doesn't support long file paths / file names.
After reading both of your posts here I am still confused. What do you
mean by "adding classes to a project". All of my projects include many
classes since they are C++ projects. How is adding a class related to
the length of a path? What path are you talking about? If you want
help please try to give enough information for use to understand what
you are trying to do.
There is a report on a problem with path lengths for a combination of
output path and library path lengths, but the paths in the report are
much longer than what you show and the problem goes away if the path
length is decreased or increased.
Report No: 60699 Status: Open
Access violation on link depending on path length
qc.codegear.com/wc/qcmain.aspx
QCWIN:Defect_No=60699
- Leo
 

{smallsort}

Re:BCB6 - Linker Error after Adding Class to Project (NTDLL.DLL)

Hi Leo,
We are modifying a Windows Application through the BCB IDE.
When you add a class (On the Tool Bar: Project ->Add to Project), it puts in the file path within the project settings file <project name>.bpr
Here is a sample of a class we added:
<FILELIST>
<FILE FILENAME="EMDeptMainMenu\MainMe{*word*198}ptMonthlyTasks\ReviewPlantGeneration\DeptMonthlyTasksCloverBarEnergyCentre.cpp" FORMNAME="" UNITNAME="DeptMonthlyTasksCloverBarEnergyCentre" CONTAINERID="CCompiler" DESIGNCLASS="" LOCALCOMMAND=""/>
</FILELIST>
We have a total of 125 classes seperated into a collection of sub-folders.
If a File is added with a deep folder path, this is what we found to cause the NTDLL error.
PS:
When we put in the our class that we were trying to add with in the project root folder, and adding it from there, it compiled fine and executed with no problems.
Placing this same class in a deep folder path caused it to fail.
~Heinz
(Hope this helps someone else, it took over a day to figure out what the hell was wrong)
Leo Siefert < XXXX@XXXXX.COM >wrote:
Quote
Heinz Ketchup wrote:

>Apparently the Borland Project when adding
>classes doesn't support long file paths / file names.

After reading both of your posts here I am still confused. What do you
mean by "adding classes to a project". All of my projects include many
classes since they are C++ projects. How is adding a class related to
the length of a path? What path are you talking about? If you want
help please try to give enough information for use to understand what
you are trying to do.

There is a report on a problem with path lengths for a combination of
output path and library path lengths, but the paths in the report are
much longer than what you show and the problem goes away if the path
length is decreased or increased.

Report No: 60699 Status: Open
Access violation on link depending on path length
qc.codegear.com/wc/qcmain.aspx
QCWIN:Defect_No=60699

- Leo
 

Re:BCB6 - Linker Error after Adding Class to Project (NTDLL.DLL)

Heinz Ketchup wrote:
Quote
If a File is added with a deep folder path, this is what we found to
cause the NTDLL error.

When we put in the our class that we were trying to add with in the
project root folder, and adding it from there, it compiled fine and
executed with no problems.

Placing this same class in a deep folder path caused it to fail.
Probably you exceeds system MAX_PATH (260 symbols).
Then you create a file the path lenght is still valid and file creation
is successful.
But when you add this file into the project the IDE creates relative
path which can be longer and is not valid.
--
Alex
 

Re:BCB6 - Linker Error after Adding Class to Project (NTDLL.DLL)

Heinz Ketchup wrote:
Quote
We have a total of 125 classes seperated
into a collection of sub-folders.
So by "classes" you mean .cpp files. After looking at the entry from
your project file, it is clear that your path variable is getting
long, and the error is coming from ntdll.dll, which is part of the OS,
not under the control of CodeGear, so you will have to live with its
limitations.
With only 125 .cpp files, why do you feel need to keep them so deeply
nested? And it appears that you have the project's home directory on a
separate drive. You can probably solve your problem by simply
arranging your project more logically. It's not necessary for all of
the files to be in the same directory, but it helps if they are all in
subdirectories of the project directory - paths are then shorter.
If your files are shared by a number of different projects, then all
of the .cbproj files can be in the main project group directory, and
perhaps added to a project group in the IDE if you wish. Then the
source files can be in various subdirectories under that main
directory, which will shorten the paths (as well as making it much
easier to back up the project files).
For files that are shared by many unrelated projects, which the
example appears not to be, you can do what I have done and make a
single "lib" folder in some location and always add that location to
your path. Then the include path variable can be relative to that
location.
Also, while descriptive file and folder names are generally a good
idea, IMHO you seem to have gone overboard in this direction, Simply
shortening the folder and file names may well solve the problem
without actually rearranging them entirely, but you might also
consider the fact that with descriptive file names more could be
grouped into a higher-level folder since as it is there is duplication
in the file and folder names.
If you really feel a need to continue with exactly the same
file/folder names and arrangement, there are still some ways around
your problem. I assume that it is the include path that is actually
blowing out in ntdll, so what you really need to do is shorten that.
One way is to eliminate any include path entries that do not contain
required header files.
Another is to call the header file with a full path so that the path
does not need to be in the include path, but you will have to remember
to remove the path when the IDE adds it automatically.
Short of changing the directory structure, however, the best solution
would be to assign one or more environment variables to substitute for
long path names. Then you can substitute these into the include path
as appropriate to shorten it.
If it were my project, however, I would simply put all 125 source
files and their associated headers into the main project directory.
Then you can use the Project Manager in the IDE to create the logical
arrangement that you want and it will have no impact on the path.
- Leo
 

Re:BCB6 - Linker Error after Adding Class to Project (NTDLL.DLL)

"AlexB" < XXXX@XXXXX.COM >wrote in message
Quote
Heinz Ketchup wrote:

>Placing this same class in a deep folder path caused it to fail.

Probably you exceeds system MAX_PATH (260 symbols).

Then you create a file the path lenght is still valid and file creation
is successful.

It would be nice if this was the case, 'cuz then you'd have sort of a
deterministic reason that you could anticipate and generally avoid.
BUT unfortunately with bds2006, we have had problems with paths that were
_much_ less than 260 chars/bytes long. (The problem that Leo (?) referenced
about link working/not-working with a path being longer/shorter than
something specific has seemed to be our situation.)
CodeGear has had a reproducible scenario demonstrating one of our linker
path-related problems for several months (and back around March confirmed
the ability to reproduce it) but I don't know what may be happening with
addressing that particular issue.
I suspect there are actually several different manifestations of a (some?)
path-related problem(s) (occurring with paths much less than the 256/260
maximum path limit):
1)linker fails reporting it can't find certain symbols (but doesn't if same
project/source is built in "acceptably" different named path),
2)a bad executable is produced with no indication of errors (but doesn't if
same project/source is built in "acceptably" different named path),
3)linker may fail with access/violation.
We've experienced both 1 and 2, and it would seem this thread is indicative
of 3 as well.
 

Re:BCB6 - Linker Error after Adding Class to Project (NTDLL.DLL)

In addition to what AlexB said, please check the full file and path name for
'+', '-' characters and for the mixing of both forward and back slashes in
the same path. Also check the IDE's path settings for two adjacent
semicolons.
. Ed
Quote
dhoke wrote in message
news: XXXX@XXXXX.COM ...

It would be nice if this was the case, 'cuz then you'd have sort of a
deterministic reason that you could anticipate and generally avoid.

BUT unfortunately with bds2006, we have had problems with paths that were
_much_ less than 260 chars/bytes long. (The problem that Leo (?)
referenced about link working/not-working with a path being longer/shorter
than something specific has seemed to be our situation.)

CodeGear has had a reproducible scenario demonstrating one of our linker
path-related problems for several months (and back around March confirmed
the ability to reproduce it) but I don't know what may be happening with
addressing that particular issue.

I suspect there are actually several different manifestations of a (some?)
path-related problem(s) (occurring with paths much less than the 256/260
maximum path limit):
1)linker fails reporting it can't find certain symbols (but doesn't if
same project/source is built in "acceptably" different named path),
2)a bad executable is produced with no indication of errors (but doesn't
if same project/source is built in "acceptably" different named path),
3)linker may fail with access/violation.

We've experienced both 1 and 2, and it would seem this thread is
indicative of 3 as well.
 

Re:BCB6 - Linker Error after Adding Class to Project (NTDLL.DLL)

Thanks Everyone for your Responses!
They are greatly appreciated!
It is nice to see that there is still a community around BCB.
(IMHO) Everywhere you look it's C# nowadays.
Well, I think it's fair to say we definitely have gone overboard with the file / folder naming structure.
The suggestions of limiting path lengths is probably what we will be doing now. We will get a group consensus to see which ones make the most sense/ease to implement.
I just wish we had known this sooner.
Again, much appreciated for all the feedback, and good to know we weren't the only ones =D
Which really isn't a good thing. I guess Misery enjoys company!
Cheers Everyone!
~Heinz