Originally posted by: donk@dshovax.UUCP (don kinzer x2192)
Message-ID: <218@dshovax.UUCP>
Date: Thu, 10-Jan-85 13:41:12 EST
Article-I.D.: dshovax.218
Posted: Thu Jan 10 13:41:12 1985
Date-Received: Mon, 14-Jan-85 03:38:16 EST
Distribution: net
Organization: Intel Corp., Hillsboro, OR
Lines: 44
I have run into a problem on the PC that has me stumped. We were developing
an application using Lattice C V2.12 and everything was going well. When
we started to debug a previously untested section of code it was noticed that
certain initialized variables (strings) were being corrupted. The usual
suspects were checked (bad pointers, etc) to no avail. It was then noticed
that the strings were corrupted even before executing any code, that is,
say debug app.exe then go look at the string storage and it's already blasted.
We are absolutely certain that the memory locations being inspected are the
correct ones.
This led us to believe that maybe the .exe file was corrupted. Checking it
revealed that the load image was correct! From this we concluded that somehow
the load process is blasting the data areas in question.
Other observations that may provide hints (not obvious to us) are:
1. Making changes to the program, such as adding more data declarations in
lower addressed modules caused debug to hang when loading the .exe file
but the exact same .exe was loaded successfully when executed directly
(without debug). [This was observed on an AT, it is unknown whether
the same symptom appears under earlier DOS versions.]
2. When linking the application with either the IBM linker V2.2 (provided
with the AT) or the Microsoft V2.4 linker the same results are observed
under both DOS V2.1 and DOS V3.0. Moreover, it was noticed that the
"sorted by value" section of the public symbol map was no longer correctly
sorted; data and code values were intermixed!
Note that this application is currently small model (separate code and data
segments) with the code segment being about 0xc000 long and the data segment
being about 0x7000 long.
We're currently chopping out parts of the program to get it back to a semi-
working state after which we'll start adding sections back to see when it
breaks. This is a tedious process but we're out of ideas. Can anyone
give us some clues???
Thanks,
Don Kinzer
... hplabs!intelca!omovax!dshovax!donk