Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site dshovax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!zehntel!dual!qantel!intelca!omovax!dshovax!donk From: donk@dshovax.UUCP (don kinzer x2192) Newsgroups: net.micro.pc Subject: PC linker problem?? Message-ID: <219@dshovax.UUCP> Date: Thu, 10-Jan-85 13:48:24 EST Article-I.D.: dshovax.219 Posted: Thu Jan 10 13:48:24 1985 Date-Received: Mon, 14-Jan-85 03:38:42 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