Discussion:
BDS2007, Global variable gets resolved to two diffrent addresses?
(too old to reply)
Larry Griffiths
2008-07-14 18:39:02 UTC
Permalink
I am using BDS2007 under Windows XP with service pack 2 applied.

I have a global in a package unit that is assigned a new instance of a class
and I record that address .

That global is used in another place in the package unit but the assembler
code is showing a register being loaded with a completely different absolute
address ( I think )
which has a value of NULL and causes an exception.

Is anyone aware of any problems like this with Globals or perhaps linker
problems that are causing code to be filled in with different addresses for
a global.

Larry Griffiths.
Larry Griffiths
2008-07-14 18:49:16 UTC
Permalink
Another thing I noticed is that the Inspector shows an address of the global
when the global is assigned the address of an instance of an object
that is entirely different address of the global later when debugging.

Larry.
Post by Larry Griffiths
I am using BDS2007 under Windows XP with service pack 2 applied.
I have a global in a package unit that is assigned a new instance of a
class and I record that address .
That global is used in another place in the package unit but the assembler
code is showing a register being loaded with a completely different
absolute address ( I think )
which has a value of NULL and causes an exception.
Is anyone aware of any problems like this with Globals or perhaps linker
problems that are causing code to be filled in with different addresses
for a global.
Larry Griffiths.
Helmut Giese
2008-07-14 18:54:36 UTC
Permalink
On Mon, 14 Jul 2008 13:39:02 -0500, "Larry Griffiths"
Post by Larry Griffiths
I am using BDS2007 under Windows XP with service pack 2 applied.
I have a global in a package unit that is assigned a new instance of a class
and I record that address .
That global is used in another place in the package unit but the assembler
code is showing a register being loaded with a completely different absolute
address ( I think )
which has a value of NULL and causes an exception.
Is anyone aware of any problems like this with Globals or perhaps linker
problems that are causing code to be filled in with different addresses for
a global.
Hi Larry,
one reason would be that you have 2 _definitions_ of the same global
variable.
File a.cpp contains a statement like 'int globVar;'
and file b.cpp a similar one: 'int globVar ;'

I think that you should get a linker warning in this case but I don't
know about packages.
Now, what happens is that one part of your app uses 'globVar' from
file a.cpp, while another part uses 'globVar' from file b.cpp - BOOM.

Try to run grep on all your sources involved - hopefully this turns up
the culprit.
HTH
Helmut Giese
Larry Griffiths
2008-07-14 19:18:51 UTC
Permalink
Thanks for your input to our problem, Helmut.

We did search code for the duplicate but did not find one. I should have
posted this information in my initial post.

All of our package projects have "Use runtime packages" turned off. ( I
dont think the option can even be set on for a package project ).

The .exe project had "Use runtime packages" checked. Somehow the global
gets assigned different addresses when this happens?

I am putting code in my project checker to flag if any of our projects has
"Use runtime packages" checked.

Larry.
Post by Helmut Giese
On Mon, 14 Jul 2008 13:39:02 -0500, "Larry Griffiths"
Post by Larry Griffiths
I am using BDS2007 under Windows XP with service pack 2 applied.
I have a global in a package unit that is assigned a new instance of a class
and I record that address .
That global is used in another place in the package unit but the assembler
code is showing a register being loaded with a completely different absolute
address ( I think )
which has a value of NULL and causes an exception.
Is anyone aware of any problems like this with Globals or perhaps linker
problems that are causing code to be filled in with different addresses for
a global.
Hi Larry,
one reason would be that you have 2 _definitions_ of the same global
variable.
File a.cpp contains a statement like 'int globVar;'
and file b.cpp a similar one: 'int globVar ;'
I think that you should get a linker warning in this case but I don't
know about packages.
Now, what happens is that one part of your app uses 'globVar' from
file a.cpp, while another part uses 'globVar' from file b.cpp - BOOM.
Try to run grep on all your sources involved - hopefully this turns up
the culprit.
HTH
Helmut Giese
dhoke
2008-07-14 20:01:37 UTC
Permalink
Your global var isn't perchance "extern"d in a header, with an
initialization clause?

i.e.
extern int myglobal = 0 ;

as that would produce a global definition in any file that happened to
include/contain the declaration...

longshot, but thought I'd ask, in case...
Post by Larry Griffiths
Thanks for your input to our problem, Helmut.
We did search code for the duplicate but did not find one. I should have
posted this information in my initial post.
Larry Griffiths
2008-07-14 20:03:28 UTC
Permalink
I cannot change "Use runtime packages" for package projects but for some
unknown reason I have a "UsePackages" tag with a value of "true" in some of
my package .cbproj files.

I am removeing these tags by hand for the package .cbproj files.

I wonder if "Use runtime packages" could be set before the december update
and then was not allowed to be changed after the December update.

Larry
Post by Larry Griffiths
Thanks for your input to our problem, Helmut.
We did search code for the duplicate but did not find one. I should have
posted this information in my initial post.
All of our package projects have "Use runtime packages" turned off. ( I
dont think the option can even be set on for a package project ).
The .exe project had "Use runtime packages" checked. Somehow the global
gets assigned different addresses when this happens?
I am putting code in my project checker to flag if any of our projects has
"Use runtime packages" checked.
Larry.
Post by Helmut Giese
On Mon, 14 Jul 2008 13:39:02 -0500, "Larry Griffiths"
Post by Larry Griffiths
I am using BDS2007 under Windows XP with service pack 2 applied.
I have a global in a package unit that is assigned a new instance of a class
and I record that address .
That global is used in another place in the package unit but the assembler
code is showing a register being loaded with a completely different absolute
address ( I think )
which has a value of NULL and causes an exception.
Is anyone aware of any problems like this with Globals or perhaps linker
problems that are causing code to be filled in with different addresses for
a global.
Hi Larry,
one reason would be that you have 2 _definitions_ of the same global
variable.
File a.cpp contains a statement like 'int globVar;'
and file b.cpp a similar one: 'int globVar ;'
I think that you should get a linker warning in this case but I don't
know about packages.
Now, what happens is that one part of your app uses 'globVar' from
file a.cpp, while another part uses 'globVar' from file b.cpp - BOOM.
Try to run grep on all your sources involved - hopefully this turns up
the culprit.
HTH
Helmut Giese
Remy Lebeau (TeamB)
2008-07-14 20:13:28 UTC
Permalink
Post by Larry Griffiths
We did search code for the duplicate but did not find one. I should have
posted this information in my initial post.
Are you declaring the variable in a header file without using 'extern'? If
so, then every unit that includes that header file is going to get its own
local copy of the variable. That would account for the behavior you are
seeing.


Gambit
Larry Griffiths
2008-07-15 00:05:48 UTC
Permalink
I declared the variable in the .cpp file without anything in a header.

TSomeClass* GlobalVariable = 0;

This unit is in a package that gets .bpi entries in the requires section of
other package projects
and a .lib in the .exe package.

Can you explain to me what happened, Remy?

Larry.
Post by Remy Lebeau (TeamB)
Post by Larry Griffiths
We did search code for the duplicate but did not find one. I should have
posted this information in my initial post.
Are you declaring the variable in a header file without using 'extern'?
If so, then every unit that includes that header file is going to get its
own local copy of the variable. That would account for the behavior you
are seeing.
Gambit
Remy Lebeau (TeamB)
2008-07-15 00:49:01 UTC
Permalink
Post by Larry Griffiths
I declared the variable in the .cpp file without anything in a header.
TSomeClass* GlobalVariable = 0;
If that were the case, then your package would only be able to have 1 copy
of the variable. So something else has to be going on that you have not
shown yet. How are you actually using the variable?


Gambit
Larry Griffiths
2008-07-15 01:27:43 UTC
Permalink
Something like this.

I can post the actual methods when I am at work.

TSomeClass* GlobalVariable = 0;

TSomeClass::TSomeClass( TStringGrid* _StringGrid )
{
// Global variable has a valid address after it is assigned new instance
of TSomeClass;
GlobalVariable = new TSomeClass;

}

void TSomeClass::Method( long _long )
{
// GobalVariable is NULL when it enters this method call.
// The CPU instruction stepping shows a different absolute address for
GlobalVariable being loaded into a register here.
GlobalVariable->long = _long;
}

Larry.
Post by Remy Lebeau (TeamB)
Post by Larry Griffiths
I declared the variable in the .cpp file without anything in a header.
TSomeClass* GlobalVariable = 0;
If that were the case, then your package would only be able to have 1 copy
of the variable. So something else has to be going on that you have not
shown yet. How are you actually using the variable?
Gambit
Leo Siefert
2008-07-15 11:45:48 UTC
Permalink
Post by Larry Griffiths
TSomeClass::TSomeClass( TStringGrid* _StringGrid )
{
GlobalVariable = new TSomeClass;
}
Huh? So what does the default constructor for TSomeClass do? I hope it
doesn't also assign GlobalVariable to another new instance...

At any rate, it appears clear that TSomeClass is not a singleton, yet
it assigns a default constructed new TSomeClass to GlobalVariable
every time a TSomeClass is constructed from a TStringGrid* (including
any time a TStringGrid* is assigned to a TSomeClass* variable.

Pretty easy to see how the value of GlobalVariable can be changed by
seemingly innocent looking code. Almost impossible to find with a
grep.

- Leo
Larry Griffiths
2008-07-15 14:03:29 UTC
Permalink
You are correct, Leo.

I do not like doing it this way but we pass this as a parms to the TList
Sort method. I wish the TList Sort would pass a TList pointer like
TStringList Sort does. I could then Create a descendant of TList and stick
the sort parmaters inside of it and be able to access it from the TList Sort
Method.

The assembler instructions in TSortGrid::ColumnIsDuplicate are loading a
different address for the SortGridConfig variable then the one that the
TSortGrid::TSortGrid uses when it creates and instance of TSortGridConfig
and assigns it to SortGridConfig.

This is only happening when we have "Use runtime packages" checked in the
.exe file that uses the code shown below ( which is in a package type
project ).

Here is the code:

################# .h header ###########################
//------------------------------------------------------------------------------
class TSortGridConfig : public TObject
{
public:

__fastcall TSortGridConfig();
__fastcall ~TSortGridConfig();

long KeyDepth;
TObjectList* SortParametersList;
TList* OriginalPositions;
TObjectList* SortKeyOLs;
};

################ .cpp body ####################

TSortGridConfig* SortGridConfig = 0;

##########

__fastcall TSortGridConfig::TSortGridConfig()
{
KeyDepth = 0;
OriginalPositions = new TList;
SortKeyOLs = new TObjectList;
SortParametersList = new TObjectList;
}
//------------------------------------------------------------------------------
__fastcall TSortGridConfig::~TSortGridConfig()
{
delete OriginalPositions;
delete SortKeyOLs;
delete SortParametersList;
}

###########

//------------------------------------------------------------------------------
__fastcall TSortGrid::TSortGrid( TStringGrid* _StringGrid )
{
SortGridConfig = new TSortGridConfig;
FStringGrid = _StringGrid;
}

//------------------------------------------------------------------------------
__fastcall TSortGrid::~TSortGrid()
{
delete SortGridConfig;
SortGridConfig = 0;
}

//------------------------------------------------------------------------------
bool __fastcall TSortGrid::ColumnIsDuplicate( long _Col, TGridSortType
_GridSortType )
{
bool Result = false;

for( int ix = 0; ix < SortGridConfig->SortParametersList->Count; ix++ )
{
TSortParameters* SortParameters =
(TSortParameters*)SortGridConfig->SortParametersList->Items[ix];
if( SortParameters->Column == _Col )
{
Result = true;

// It is ok to use the same column if keys from the grid are
String and Object

if( ( _GridSortType == stTInteger || _GridSortType ==
stTString ) &&
( SortParameters->GridSortType == stString ||
SortParameters->GridSortType == stNumeric || SortParameters->GridSortType ==
stDate )
)
{
Result = false;
}
}
}

return Result;
}
//------------------------------------------------------------------------------
void __fastcall TSortGrid::AddCol( long _Col, TGridSortType
_GridSortType, TSortDirection _SortDirection, String _DateMask )
{
// Save sort parameters

if( ColumnIsDuplicate( _Col, _GridSortType ) )
{
return;
}

if ( _Col >= FStringGrid->FixedCols && _Col < FStringGrid->ColCount )
{
TSortParameters* SortParameters = new TSortParameters;
SortParameters->Column = _Col ;
SortParameters->GridSortType = _GridSortType ;
SortParameters->SortDirection = _SortDirection ;
SortGridConfig->SortParametersList->Add( SortParameters );

BuildKeys( _Col, _GridSortType, _DateMask );
}
}
Post by Leo Siefert
Post by Larry Griffiths
TSomeClass::TSomeClass( TStringGrid* _StringGrid )
{
GlobalVariable = new TSomeClass;
}
Huh? So what does the default constructor for TSomeClass do? I hope it
doesn't also assign GlobalVariable to another new instance...
At any rate, it appears clear that TSomeClass is not a singleton, yet
it assigns a default constructed new TSomeClass to GlobalVariable
every time a TSomeClass is constructed from a TStringGrid* (including
any time a TStringGrid* is assigned to a TSomeClass* variable.
Pretty easy to see how the value of GlobalVariable can be changed by
seemingly innocent looking code. Almost impossible to find with a
grep.
- Leo
Larry Griffiths
2008-07-15 15:06:42 UTC
Permalink
Here is what happens at the assembler level when the .exe project has "Use
runtime packages" checked.

####################################

SortGridU.cpp.217: MySortGridConfig = new TSortGridConfig;
01D42170 B201 mov dl,$01
01D42172 A1C429D501 mov eax,[$01d529c4]
01D42177 E8CCFDFFFF call TSortGridConfig::TSortGridConfig()
01D4217C A38822D501 mov [$01d52288],eax <------------ eax(
0x0D76C45C )
SortGridU.cpp.218: FStringGrid = _StringGrid;
01D42181 8B55FC mov edx,[ebp-$04]


########## Debug Inspector #########

MySortGridConfig: TSortGridConfig * :01D52288 : :0D76C45C

####################################


SortGridU.cpp.256: for( int ix = 0; ix <
MySortGridConfig->SortParametersList->Count; ix++ )
00556074 FF45EC inc dword ptr [ebp-$14]
00556077 8B1530A7CB00 mov edx,[$00cba730] <--------------- edx(
0x00000000 )
0055607D 8B4A08 mov ecx,[edx+$08]
00556080 8B4108 mov eax,[ecx+$08]
00556083 3B45EC cmp eax,[ebp-$14]
00556086 7F9E jnle $00556026
SortGridU.cpp.274: return Result;
00556088 8A45F3 mov al,[ebp-$0d]

########## Debug Inspector #########

MySortGridConfig: TSortGridConfig * :00CBA730 : NULL
dhoke
2008-07-15 15:20:15 UTC
Permalink
Post by Larry Griffiths
Here is what happens at the assembler level when the .exe project has "Use
runtime packages" checked.
01D4217C A38822D501 mov [$01d52288],eax <------------ eax(
00556077 8B1530A7CB00 mov edx,[$00cba730] <--------------- edx(
0x00000000 )
Have you tried generating a map file, and seeing what (how many?) reports
there are for MySortGridConfig, and what its address(es) are? Those
definitely don't look the same, perhaps Chris U's suggestion is worthy of
consideration... (one for .bpi and one for .lib)
Larry Griffiths
2008-07-15 16:57:11 UTC
Permalink
These are the .map entries of the .lib .bpi .bpl project.

0001:00024E1C _IsPlatformNT
0002:00008288 _MySortGridConfig
0001:000268C1 __AfterConstruction

0002:00008200 TSecureKey::
0002:00008288 _MySortGridConfig
0002:00008288 Sortgridu::D55_1

These are the .map entries of the .exe project.

0002:00282478 _MyRegistry
0002:00056140 _MySortGridConfig
0002:00270588 _NEWSTAGEFORM

0002:00056140 Sortgridu::D743_1
0002:00056140 _MySortGridConfig
0002:0005618C __chtbl__ __fastcall CustomSortProc(void *, void *)

### This is with "Use runtime packages" checked which causes the exception.

0002:00273180 _MyRegistry
0002:00056850 _MySortGridConfig
0002:00261118 _NEWSTAGEFORM

0002:00056850 Sortgridu::D2054_1
0002:00056850 _MySortGridConfig
0002:0005689C __chtbl__ __fastcall CustomSortProc(void *, void *)
Post by dhoke
Post by Larry Griffiths
Here is what happens at the assembler level when the .exe project has
"Use runtime packages" checked.
01D4217C A38822D501 mov [$01d52288],eax <------------ eax(
00556077 8B1530A7CB00 mov edx,[$00cba730] <--------------- edx(
0x00000000 )
Have you tried generating a map file, and seeing what (how many?) reports
there are for MySortGridConfig, and what its address(es) are? Those
definitely don't look the same, perhaps Chris U's suggestion is worthy of
consideration... (one for .bpi and one for .lib)
Larry Griffiths
2008-07-15 17:42:17 UTC
Permalink
Hmm, the problem seems to have gone away. I did a release build.

One of my team members has made a couple of changes to our projects that I
am aware of.

Some of our projects had more than the debug and release folders. There
were some projects that had debug_build and release_build directories in
addition to release and debug directories and he made them all release or
debug.

He also gave names to the pre-compiled header files like MyProject.csm. He
said he preferred that projects not use pre-compiled headers from other
projects.

I am doing a debug build now and will see if the problem occurs in a debug
build.


If the problem is absent in the debug build then I will remove the
MyProject.csm entries and see if the problem comes back.

Larry.
Post by dhoke
Post by Larry Griffiths
Here is what happens at the assembler level when the .exe project has
"Use runtime packages" checked.
01D4217C A38822D501 mov [$01d52288],eax <------------ eax(
00556077 8B1530A7CB00 mov edx,[$00cba730] <--------------- edx(
0x00000000 )
Have you tried generating a map file, and seeing what (how many?) reports
there are for MySortGridConfig, and what its address(es) are? Those
definitely don't look the same, perhaps Chris U's suggestion is worthy of
consideration... (one for .bpi and one for .lib)
Larry Griffiths
2008-07-15 18:08:24 UTC
Permalink
I removed a class PACKAGE that I had added to the TGridSort class and
re-built everything.

The failure returned.

The PACKAGE fixes the global variable exception for some reason.

I guess I will put PACKAGE back on the class and look at linker maps again.

Larry.
Post by Larry Griffiths
Hmm, the problem seems to have gone away. I did a release build.
One of my team members has made a couple of changes to our projects that I
am aware of.
Some of our projects had more than the debug and release folders. There
were some projects that had debug_build and release_build directories in
addition to release and debug directories and he made them all release or
debug.
He also gave names to the pre-compiled header files like MyProject.csm.
He said he preferred that projects not use pre-compiled headers from other
projects.
I am doing a debug build now and will see if the problem occurs in a debug
build.
If the problem is absent in the debug build then I will remove the
MyProject.csm entries and see if the problem comes back.
Larry.
Post by dhoke
Post by Larry Griffiths
Here is what happens at the assembler level when the .exe project has
"Use runtime packages" checked.
01D4217C A38822D501 mov [$01d52288],eax <------------ eax(
00556077 8B1530A7CB00 mov edx,[$00cba730] <--------------- edx(
0x00000000 )
Have you tried generating a map file, and seeing what (how many?) reports
there are for MySortGridConfig, and what its address(es) are? Those
definitely don't look the same, perhaps Chris U's suggestion is worthy of
consideration... (one for .bpi and one for .lib)
Larry Griffiths
2008-07-15 19:20:13 UTC
Permalink
I have been removing the class PACKAGE from many of the classes in our
package projects lately.

The linker gives errors for classes that need to be exported when "Use
runtime packages" is not checked.

It appears that if "Use runtime packages" needs to be used at any time in
the future then a Golden rule currently
applies to BDS2007.

This Golden rule is "Always use class PACKAGE in package projects".

Im not sure what is going on under the covers but im in FIDO mode now.

Thanks for everyones help.
Post by Larry Griffiths
I removed a class PACKAGE that I had added to the TGridSort class and
re-built everything.
The failure returned.
The PACKAGE fixes the global variable exception for some reason.
I guess I will put PACKAGE back on the class and look at linker maps again.
Larry.
Post by Larry Griffiths
Hmm, the problem seems to have gone away. I did a release build.
One of my team members has made a couple of changes to our projects that
I am aware of.
Some of our projects had more than the debug and release folders. There
were some projects that had debug_build and release_build directories in
addition to release and debug directories and he made them all release or
debug.
He also gave names to the pre-compiled header files like MyProject.csm.
He said he preferred that projects not use pre-compiled headers from
other projects.
I am doing a debug build now and will see if the problem occurs in a
debug build.
If the problem is absent in the debug build then I will remove the
MyProject.csm entries and see if the problem comes back.
Larry.
Post by dhoke
Post by Larry Griffiths
Here is what happens at the assembler level when the .exe project has
"Use runtime packages" checked.
01D4217C A38822D501 mov [$01d52288],eax <------------ eax(
00556077 8B1530A7CB00 mov edx,[$00cba730] <--------------- edx(
0x00000000 )
Have you tried generating a map file, and seeing what (how many?)
reports there are for MySortGridConfig, and what its address(es) are?
Those definitely don't look the same, perhaps Chris U's suggestion is
worthy of consideration... (one for .bpi and one for .lib)
Tom420
2008-07-19 18:24:01 UTC
Permalink
Post by Larry Griffiths
I have been removing the class PACKAGE from many of the classes in our
package projects lately.
The linker gives errors for classes that need to be exported when "Use
runtime packages" is not checked.
It appears that if "Use runtime packages" needs to be used at any time in
the future then a Golden rule currently
applies to BDS2007.
This Golden rule is "Always use class PACKAGE in package projects".
Im not sure what is going on under the covers but im in FIDO mode now.
The PACKAGE keyword creates a separate namespace for the package.
Perhaps the default inclusion of the keyword by the IDE is useful :)
Larry Griffiths
2008-07-15 15:14:47 UTC
Permalink
Here is what happens at the assembler level when the .exe project DOES NOT
have "Use
runtime packages" checked

##################################

SortGridU.cpp.216: {
005A63EE 66C745E80C00 mov word ptr [ebp-$18],$000c
SortGridU.cpp.217: MySortGridConfig = new TSortGridConfig;
005A63F4 B201 mov dl,$01
005A63F6 A15408FA00 mov eax,[$00fa0854]
005A63FB E820FEFFFF call TSortGridConfig::TSortGridConfig()
005A6400 A34001FA00 mov [$00fa0140],eax <------- eax( 0x0D520240 )
SortGridU.cpp.218: FStringGrid = _StringGrid;
005A6405 8B55FC mov edx,[ebp-$04]


######## DEBUG INSPECTER #########

MySortGridConfig: TSortGridConfig * :00FA0140 : :0D520240

##################################

SortGridU.cpp.256: for( int ix = 0; ix <
MySortGridConfig->SortParametersList->Count; ix++ )
005A6614 FF45EC inc dword ptr [ebp-$14]
005A6617 8B154001FA00 mov edx,[$00fa0140] <-------- edx( 0D520240 )
005A661D 8B4A08 mov ecx,[edx+$08]
005A6620 8B4108 mov eax,[ecx+$08]
005A6623 3B45EC cmp eax,[ebp-$14]
005A6626 7F9E jnle $005a65c6
SortGridU.cpp.274: return Result;
005A6628 8A45F3 mov al,[ebp-$0d]

######## DEBUG INSPECTER #########

MySortGridConfig: TSortGridConfig * :00FA0140 : :0D520240
Larry Griffiths
2008-07-15 15:19:02 UTC
Permalink
This is what is showing up in the TDump of the package type project that is
used by the .exe project when I search for MySortGridConfig:

2AC815 PUBDEF '_MySortGridConfig' Segment: _DATA:0000

2C2C29 LEDATA Segment: (6) $$BNAMES Offset: 6000 Length: 0400
0000: 24 71 71 72 76 1A 40 54 4B 61 6C 6F 73 47 72 69
$***@TKalosGri
0010: 64 44 61 74 61 40 24 62 64 74 72 24 71 71 72 76
dData@$bdtr$qqrv
0020: 04 74 68 69 73 3F 40 53 79 73 74 65 6D 40 25 44
.this?@System@%D
0030: 65 6C 70 68 69 49 6E 74 65 72 66 61 63 65 24 74
elphiInterface$t
0040: 32 33 43 6C 61 73 73 65 73 40 49 53 74 72 69 6E
***@IStrin
0050: 67 73 41 64 61 70 74 65 72 25 40 24 62 64 74 72
gsAdapter%@$bdtr
0060: 24 71 71 72 76 04 74 68 69 73 1F 40 43 6F 6E 74
$***@Cont
0070: 6E 72 73 40 54 4F 62 6A 65 63 74 4C 69 73 74 40
***@TObjectList@
0080: 24 62 64 74 72 24 71 71 72 76 04 74 68 69 73 10
$bdtr$qqrv.this.
0090: 4D 79 53 6F 72 74 47 72 69 64 43 6F 6E 66 69 67
MySortGridConfig
00A0: 1C 40 43 6F 6E 74 6E 72 73 40 54 4F 62 6A 65 63
***@Contnrs@TObjec
00B0: 74 4C 69 73 74 40 47 65 74 49 74 65 6D 2C 40 44
***@GetItem,@D
00C0: 69 61 6C 6F 67 73 40 53 68 6F 77 4D 65 73 73 61
***@ShowMessa
00D0: 67 65 24 71 71 72 78 31 37 53 79 73 74 65 6D 40
ge$qqrx17System@
00E0: 41 6E 73 69 53 74 72 69 6E 67 0D 5F 43 61 74 63
AnsiString._Catc
00F0: 68 43 6C 65 61 6E 75 70 15 5F 5F 49 6E 69 74 45
hCleanup.__InitE
0100: 78 63 65 70 74 42 6C 6F 63 6B 4C 44 54 43 0C 5F
xceptBlockLDTC._
0110: 43 6C 61 73 73 43 72 65 61 74 65 12 5F 41 66 74
ClassCreate._Aft
0120: 65 72 43 6F 6E 73 74 72 75 63 74 69 6F 6E 05 5F
erConstruction._
0130: 66 74 6F 6C 31 40 53 79 73 74 65 6D 40 41 6E 73
***@System@Ans
0140: 69 53 74 72 69 6E 67 40 24 62 61 73 67 24 71 71
iString@$basg$qq
Chris Uzdavinis (TeamB)
2008-07-15 14:21:33 UTC
Permalink
Post by Larry Griffiths
I declared the variable in the .cpp file without anything in a header.
TSomeClass* GlobalVariable = 0;
This unit is in a package that gets .bpi entries in the requires section of
other package projects
and a .lib in the .exe package.
Can you explain to me what happened, Remy?
Oh, you might be getting one for the .lib and the other for the .bpi.
--
Chris (TeamB);
dhoke
2008-07-15 01:28:46 UTC
Permalink
Post by Larry Griffiths
I am using BDS2007 under Windows XP with service pack 2 applied.
Is anyone aware of any problems like this with Globals or perhaps linker
problems that are causing code to be filled in with different addresses
for a global.
For bds2006, we have on at least 2 occasions experienced a "bad" executable
being generated, where changing the output directory name seemed to resolve
the problem. (One of these was submitted to CodeGear, and after some
back-and-forth [I screwed up submission], I received an indication that they
could demonstrate the problem. I've had no word since March regarding
this.) In the original case, the executable would start and run, and
experienced "random" access violations in areas of the code that had not
had any recent changes. In the submitted case, it pretty much crashed on
startup. (There was also an intermediate case which I tried briefly with
one of the 2007 trials, and it still seemed to have the problem - I believe
CG's confirmation for the submitted repro. scenario was probably also tried
with the 2007 linker, which apparently still failed.)

Your situation does not sound quite so "pronounced", so to speak, as any of
ours - but it ought to be fairly straightforward to verify whether or not
your two areas of code are in fact accessing the same address location.

Perhaps if you are uncertain (e.g. you "( I think )"), you could capture
assembler debugger snippets from the initialization of the variable, and the
later reference, and others of us here could concur or disagree...

I have also had some success recently (with bds2006) at getting (I think) a
hardware breakpoint to work, by setting a data breakpoint, which in your
case I would create with an expression something like ("*(int*)myglobalptr
== 0), creating the breakpoint just _after_ it had been initialized with the
new instance. This might catch something else that could be zapping the
variable to NULL later, if that were happening. (In the address field for
the breakpoint, I would type the address of the location of the global
pointer, not the value that pointer contains, which I mention in the event
this isn't obvious.) This could also implicate compiler/linker, if
destructive code were found and it was not intentionally referring to your
global variable...
Post by Larry Griffiths
Larry Griffiths.
Loading...