Global variables in files without functions

[zeecanvas]

Hi,

First of all: Yes, I know global variables are bad, but I've a huge
amount of legacy code, and I've to maintain it _as_is_.

I'm maintaining a big program. I moved all (program-wide scope) global
variables outside of the files they were defined it, and created some
files that just hold global variables definitions (just variables,
without any function definition). So, depending on the purpose/category
of variables, they're defined in the proper file.

Then I created headers for these variables, that declare them with the
"extern" keyword.

Yes, the variables are read/write.

But my program crashes now. And I'm about 95% sure that this
rearrangement of variables is the reason... it looks like if when a
function writes or reads a global variable, it's not correctly written
or read.

What can be happening?

Btw, I don't know if this does matter, but the program mixes C and C++
code, taking care of the #ifdef __cplusplus extern "C" etc... (BTW, I
also put this __cplusplus construct in the header file that declares
the global variables as "extern", so that C++ code can access the C
global variables as well.

Thanks a lot in advance for all advice/suggestions.

zee

[Fred Kleinschmidt]

<ze*******@yahoo.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...

Hi,

First of all: Yes, I know global variables are bad, but I've a huge
amount of legacy code, and I've to maintain it _as_is_.

I'm maintaining a big program. I moved all (program-wide scope) global
variables outside of the files they were defined it, and created some
files that just hold global variables definitions (just variables,
without any function definition). So, depending on the purpose/category
of variables, they're defined in the proper file.

Well, It sounds like you violated your first directive - if you moved all of
those variables to a new file, you are not maintaining the code "as is".

And it looks like some of the variables you moved were not actually
program-wide in scope, but maybe just file-wide.

What was the reason for moving the variables in the first palce?
<snip>
Thanks a lot in advance for all advice/suggestions.

zee

[zeecanvas]

Fred Kleinschmidt wrote:

Well, It sounds like you violated your first directive - if you moved all of
those variables to a new file, you are not maintaining the code "as is".

And it looks like some of the variables you moved were not actually
program-wide in scope, but maybe just file-wide.

What was the reason for moving the variables in the first palce?

In this moment, that's not the point. If I move them back to their
original place, this won't help much in understanding why this odd
behaviour is taking place. I'd like to find the explanation for the
crashes I'm finding, because perhaps it has to do with the mix of C and
C++ (maybe I'm doing something wrong when linking), or perhaps there's
some memory bug which I didn't detect previously. Perhaps I'm using the
C compiler for files which require the C++ compiler, or viceversa.
Perhaps I'm declaring as extern "C" some stuff which shouldn't be
declared that way, etc...

Maybe the design choice is wrong, but that's not the point. The point
is that the program shouldn't crash, and it does (I didn't modify the
scope of the variables, since only the files that in the old version
had access to the variables do include the "extern" declarations
header, so variables are used in the same way as in the old version).
It's important to find the exact reason for these crashes.

I'd also comment that this program has been intensively debugged with
Purify, since its first versions. Even the non-important warnings
issued by Purify were fixed as soon as they were found, so I'm quite
surprised by the current crashes.

The first crash is even funny: In the second line of code. The first
line obtains a pointer to the application instance, and stores that
pointer in a global variable. The second line calls an OS function with
that pointer, and the application crashes.

If I store that pointer in a local variable, there's no crash there
(but there's a crash later when another global variable is used).

Also, if that pointer is stored a program-wide global variable, but
stored in the same file of that function that crashes, there's no crash
there. If I move it to the file with just variables (no code), it
crashes (and the variable was program-wide in the two cases, because
every file that need to access it includes the declarations header).

zee

[Rod Pemberton]

<ze*******@yahoo.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...

In this moment, that's not the point. If I move them back to their
original place, this won't help much in understanding why this odd
behaviour is taking place. I'd like to find the explanation for the
crashes I'm finding, because perhaps it has to do with the mix of C and
C++ (maybe I'm doing something wrong when linking), or perhaps there's
some memory bug which I didn't detect previously. Perhaps I'm using the
C compiler for files which require the C++ compiler, or viceversa.
Perhaps I'm declaring as extern "C" some stuff which shouldn't be
declared that way, etc...

Maybe the design choice is wrong, but that's not the point. The point
is that the program shouldn't crash, and it does (I didn't modify the
scope of the variables, since only the files that in the old version
had access to the variables do include the "extern" declarations
header, so variables are used in the same way as in the old version).
It's important to find the exact reason for these crashes.

I'd also comment that this program has been intensively debugged with
Purify, since its first versions. Even the non-important warnings
issued by Purify were fixed as soon as they were found, so I'm quite
surprised by the current crashes.

The first crash is even funny: In the second line of code. The first
line obtains a pointer to the application instance, and stores that
pointer in a global variable. The second line calls an OS function with
that pointer, and the application crashes.

If I store that pointer in a local variable, there's no crash there
(but there's a crash later when another global variable is used).

Also, if that pointer is stored a program-wide global variable, but
stored in the same file of that function that crashes, there's no crash
there. If I move it to the file with just variables (no code), it
crashes (and the variable was program-wide in the two cases, because
every file that need to access it includes the declarations header).

It sounds like Fred touched upon the problem:

And it looks like some of the variables you moved were not actually
program-wide in scope, but maybe just file-wide.

Fred was pointing out that you may have two or more variables with the same
name. Both of these had scope, but now there is only one variable with
global scope. That seems to me to be a logical guess at this point in time
to what is happening. I once worked on an application (in PL/1) that global
pointer variable which pointed to one function in half the code and another
function in the other half by design. As your statements show, their is
obviously a scope related issue with some of the variables that you
currently believe to be global. Back out each problem variable in turn
until the problem goes away.
Rod Pemberton

[Ben C]

On 2006-03-16, ze*******@yahoo.com <ze*******@yahoo.com> wrote:

Fred Kleinschmidt wrote:
[...] I'd like to find the explanation for the crashes I'm finding,
because perhaps it has to do with the mix of C and C++ (maybe I'm
doing something wrong when linking), or perhaps there's some memory
bug which I didn't detect previously. Perhaps I'm using the C compiler
for files which require the C++ compiler, or viceversa. Perhaps I'm
declaring as extern "C" some stuff which shouldn't be declared that
way, etc...
I don't think extern "C" should make any difference for variables, C++
only mangles names of functions. So you could probably get rid of all
those. But it might not make any difference. Unless it's exercising the
linker bug.
The first crash is even funny: In the second line of code. The first
line obtains a pointer to the application instance, and stores that
pointer in a global variable. The second line calls an OS function
with that pointer, and the application crashes. If I store that pointer in a local variable, there's no crash there
(but there's a crash later when another global variable is used). Also, if that pointer is stored a program-wide global variable, but
stored in the same file of that function that crashes, there's no
crash there. If I move it to the file with just variables (no code),
it crashes (and the variable was program-wide in the two cases,
because every file that need to access it includes the declarations
header).

It does sound like some kind of linker problem from what you describe.

Is the crash a null pointer read? I have once encountered a linker that
left some references unlinked, leaving them as calls to 0 (it was
functions in that case, not globals). If you use a debugger on it when
it crashes and look at the disassembly, you should expect to see an
actual address in the disassembly as a constant value somewhere around
where you're writing to the global. If you're writing to *0, then that
points the finger at a linker problem. If you're writing to what looks
like a valid address, try putting some code that writes (or reads) the
same global variable in the module in which the variable is defined, and
step that in the debugger, to see if your two modules have ended up with
a different idea of where this variable is supposed to be.

If a debugger is not practical to run, you can actually just as easily
do the same experiment with a disassembler. Write a function in each of
the two files: the one that defines the globals and the one that
crashes. Call the functions something you will be able to grep for
easily. Make the code in the functions extremely simple, it should just
read the global variable, and return its value (don't make it so simple
the compiler optimizes it away altogether). Compile and link. Then
disassemble the executable (not the .o files) with e.g. objdump -d. If
you have the GNU tools, objdump will probably work even if you aren't
using gcc. Compare the asm for your two simple functions, are they
working with the same addresses for the global? They obviously should
be.

This will hopefully confirm a linker problem. Then you have to try to
fix that... It might be a bug, or your build might include strange
things like linker scripts that have problems in them.

[zeecanvas]

ze*******@yahoo.com wrote:

it looks like if when a
function writes or reads a global variable, it's not correctly written
or read.

It's been fixed. The funny thing is that the man who actually found the
cause for the crashes did it by private mail because of being shy to
post in a group full of experts.

Diagnostic: Access to some global variables could cause crashes because
they were defined as arrays but declared as pointers. Read section 6 of
the FAQ.

Fix: Trivial, just fix the declarations in the headers.

Comments: The old version of the program worked by accident. I'm glad I
tried to find the exact cause of the problem instead of moving the
variables back to their original places, because otherwise the program
could have crashed in the future and it would have been harder to
diagnose.

Thanks to all for your time, and specially to the "shy man", who was
able to guess the problem.

zee

[Rod Pemberton]

<ze*******@yahoo.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...

ze*******@yahoo.com wrote:

it looks like if when a
function writes or reads a global variable, it's not correctly written
or read.

It's been fixed. The funny thing is that the man who actually found the
cause for the crashes did it by private mail because of being shy to
post in a group full of experts.

Diagnostic: Access to some global variables could cause crashes because
they were defined as arrays but declared as pointers. Read section 6 of
the FAQ.

Fix: Trivial, just fix the declarations in the headers.

Comments: The old version of the program worked by accident. I'm glad I
tried to find the exact cause of the problem instead of moving the
variables back to their original places, because otherwise the program
could have crashed in the future and it would have been harder to
diagnose.

Thanks to all for your time, and specially to the "shy man", who was
able to guess the problem.

The "shy man" should know that
1) the people here are of many different skill levels and backgrounds
2) "he" shouldn't ever be afraid to post
3) everyone, including "experts," miss things
Rod Pemberton

[CBFalconer]

Rod Pemberton wrote:

<ze*******@yahoo.com> wrote in message

.... snip ...

Thanks to all for your time, and specially to the "shy man", who
was able to guess the problem.

The "shy man" should know that
1) the people here are of many different skill levels and backgrounds
2) "he" shouldn't ever be afraid to post
3) everyone, including "experts," miss things

We are especially hard on lazy students who want to have their
homework done for them. We also get annoyed at people who refuse
to go along with newsgroup standards after having had them pointed
out.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>