31 character common block variable causing exe to corrupt itself

[Lynn McGuire]

I just figured out that a 31 character common block variable is causing my Win32 DLL to corrupt itself for completely unrelated
calculations. My DLL is over 10 MB and the code (800,000 lines of Fortran, C and C++ code) is very proprietary so I will not post it.

If I cut the variable name to 30 characters then the corruption goes away.

Any thoughts here? Watcom F77 is suppose to support up to 32 character variable names.

Thanks,
Lynn

[Robert Miles]

Have you tried changing it to 32 characters and seeing if that also
makes the corruption go away?

Have you tried inserting another variable into the common block just
after the variable giving the problem with no use of this extra variable
except to see if it makes the corruption go away?

Have you checked if this variable name or the common block name happens
to match one of the mangled names produced by the C++ compiler?

[Lynn McGuire]

No on the 32 characters (palm plant to forehead).

Yes, I moved the 31 character variable to an entire new common block and the problem persisted.

I have name mangling turned off for all my C++ code in the Win32 DLL. But if the variable name had matched the another symbol name
then the linker would majorly protested (had one of those last week).

Thanks,
Lynn

[dpb]

On 11/21/2014 1:04 PM, Lynn McGuire wrote:

Missed this when it was new; did you get resolution, Lynn?

I'm somewhat confused, though, on the actual problem. Is it a character
variable in the common block that happens to be a name or the length of
the variable name itself that seems to be the issue?

I can sorta' understand an alignment problem if the former; the latter
would seem to be a major problem that would've bit long before now.

--

[Lynn McGuire]

My resolution was to drop the variable name length to 30 characters. My
corruption in a non-associated portion of the program goes away. Sadly,
the corruption is very hard to detect as it is a looping portion of the
program with many, many internal loops.

The length of the variable name is the problem.

Thanks,
Lynn

[dpb]

Can you post a code snippet that illustrates the usage that caused the
issue even if it's not the actual code if you think even just a snippet
of a common block is too propritarial to paste?

I'd like to get a handle on the particular usage that had a problem as
I'm still supporting one set of power plant applications which were
built w/ Watcom.

--

[d3x0r]

Once upon a time I ran into a similar issue with Borland 3.1; the answer
would be no; a simple code does not demonstrate the problem....

I know it's binary; but can you trace back the diff? diff in .exe ? .obj?
does F77 go to assembly first?
windows 'fc' tool is pretty weak ... doesn't re-align on figured out
diffs... diff could do a good job on binary if I remember...

Sorry; I know nothing, but hate to see unresolved issues.

[dpb]

On 11/28/2014 1:39 PM, d3x0r wrote:
> On Fri, 28 Nov 2014 06:06:56 -0800, dpb <no...@non.net> wrote:
>> On 11/28/2014 12:40 AM, Lynn McGuire wrote:

...

>>> My resolution was to drop the variable name length to 30 characters. My
>>> corruption in a non-associated portion of the program goes away. Sadly,
>>> the corruption is very hard to detect as it is a looping portion of the
>>> program with many, many internal loops.
>>>
>>> The length of the variable name is the problem.
>>
>> Can you post a code snippet that illustrates the usage that caused the
>> issue even if it's not the actual code if you think even just a
>> snippet of a common block is too propritarial to paste?
>>
>> I'd like to get a handle on the particular usage that had a problem as
>> I'm still supporting one set of power plant applications which were
>> built w/ Watcom.
>>

> Once upon a time I ran into a similar issue with Borland 3.1; the answer
> would be no; a simple code does not demonstrate the problem....

...

That the code snippet actually causes a discernible error or is
compilable wasn't the question/request -- I want to see the actual type
of use of which variable name it was that seems to be the trigger as I
don't quite follow the description.

If it is simply a variable name in a common block and that name isn't
used as a dummy argument or somesuch it makes no sense whatsoever the
length has anything to do with anything -- the variable is simply a
reference to memory.

--

[Lynn McGuire]

I will do so Monday. It will just be the 32 character name variable in
the common block as I cannot post the other 800K lines of code.

Thanks,
Lynn

[dpb]

...

No, certainly not 800K LOC; but include definitions and the usage of the
variable...particularly is it used as a dummy procedure name or similar.

--

[Lynn McGuire]

On 11/28/2014 8:06 AM, dpb wrote:

C NOTE: this variable must not be longer than 30 characters as the
C 31 character version causes the GERG thermo to fail using
C dragonlng.psd for some weird reason
common / mixed_amine_thermo / mixed_amine_thermo_heat_factor

C scaling factor for the mixed amine thermo heat of reaction
double precision mixed_amine_thermo_heat_factor

Thanks,
Lynn

[dpb]

On 11/21/2014 1:04 PM, Lynn McGuire wrote:

> I just figured out that a 31 character common block variable is causing

> my Win32 DLL to corrupt itself for completely unrelated calculations. ...

>
> If I cut the variable name to 30 characters then the corruption goes away.
>
> Any thoughts here? Watcom F77 is suppose to support up to 32 character
> variable names.

...

Don't know why this just came to me and it isn't a solution but a
hypothesis...

Perhaps the compiler uses C null-terminated strings internally for the
names and somebody only assigned 32-character length not accounting for
the null???

I've never looked at the source code so have absolutely no idea where
one would even begin to start to look to see if it's something like that
that might be a nearly trivial fixup...

Are 31- and 32-character variable names outside a COMMON identified with
separate addresses, I presume?

--

[awordined...@gmail.com]

So why is this I'm my personal email.?