Board index » cppbuilder » Building My Project Crashes BCB6 IDE

2007-08-17 01:18:39 AM
cppbuilder114
Help!
I have a DLL project that performs look-up into a table of zip code
records. This table is generated (by me) into a header file (format
shown below).
I seem to be having a problem with the number of records (79,672) in
this table... when I try to build the project, it crashes the IDE with
this error:
Assertion failed: Config, file c:\src\ilink\import.cpp, line 311
When I click OK, a message box with title "bcb.exe" states "Abnormal
program termination". I then enter an endless loop of crash dialogs
offering to send a report to Microsoft. Windows Task Manager lets me
kill the processes.
I have been experimenting with commenting out huge sections of the
header file, and although I haven't determined the maximum number of
records that can be compiled and linked, the problem definitely appears
to be one of volume.
HAVE I EXCEEDED A LIMIT I SHOULD KNOW ABOUT?
typedef struct
{
char ZipCode[6];
char CityName[29];
char CityAbbr[14];
char State[3];
char FIPS[4];
char CountyName[26];
} TZipStruct;
static TZipStruct zip_objects [] = {
{ "00501", "HOLTSVILLE ", " ", "NY", "103", "SUFFOLK " },
// 79,670 more records go here
{ "99950", "KASAAN ", " ", "AK", "130", "KETCHIKAN GATEWAY" }
};
Thanks for your help,
Kathleen
 

Kathleen wrote:
That's not what they are for.
Might be a bit large.
If putting it in it's own compulation unit (obj) doesn't fix the problem,
you might get away with adding the data as a resource (RDATA),
then using LoadResource().
 

Bob,
Thank you for the speedy reply, and for your advice. I'll try the
resource option you suggested.
Kathleen
Bob Gonder wrote:

{smallsort}

Well, I couldn't figure out how to put the table into a .RC file, so I
put the gigantico static array at the top of a .CPP file, wrote a couple
of access functions, and now it is working.
But we'll be regenerating this thing bimonthly, updating it with data
from the USPS zip code list. Am I just whistling past the graveyard
here? Will this eventually fail again?
Thanks again for your help.
Kathleen
Bob Gonder wrote:

Hi,
tracking the size of the .obj. It is possible
to blow out a linker internal tables with very
huge declarations of static data. If the .obj
size is getting around 10 meg, that is too big.
--Craig
 

If the .obj is 2 meg and moving up, e.g. to 4 meg
the linker may not handle it.
--Craig
 

Craig Farrell wrote:
the USPS adds zip codes.
I have started a thread in b.p.c.language.cpp about how to accomplish
this task dynamically. However I make this happen, the data must be
fully contained within the DLL.
One thought that occurs... what if I split up the gigantic static array
into smaller static arrays? Would I gain anything?
Thanks for your input, Craig.
Kathleen
 

Hi,
I guess there are more than one way to get a growing
.obj, e.g. global data, number of symbols, amount
of code and fixups, debug info.
As far as splitting things up, my understanding
is that reducing the amount of the overflowing item
per .obj (translation unit) was the only thing that
helped. e.g. you might try the arrays in two (or more)
.cpp's
I did a tdump of some large .obj's (tdump my.obj my.dmp)
hoping there would be some nice obvious table sizes in
the .dmp but without any luck. Still, you might try tdump
if, like you say, you are right on the edge, maybe there
will something showing about what is growing.
--Craig
 

HI again,
might be processing one module at a time, it's internal
tables must be building up for the entire link.
(so don't waste your time on my previous suggestion
split up the array(s)).
--Craig
 

Kathleen wrote:
It should write/export a flat file of your structures.
The RC could then include the flat file
I am thinking you can use it this way
ResourceID RCDATA ZipCodes.dat
If not, then have your mainenance app output the data according to Microsoft's format:
msdn2.microsoft.com/en-US/library/aa381039.aspx
It could write the entire RC file to make things easy later on.