memory fault, core dump

We have upgraded to INFORMIX-4GL Version 7.30.UC1X2 We added in one global variable (smallint) to an existing program, compiled using -shared, and it ran fine Then we set the variable = 0 and got the following error dynamic linker: program name: invalid relocation type 72 at 0X0 killed If any other code is added, we get a memory fault core dump If we recompile with all the code, using -static, the problem goes away and the program runs fine Any ideas? Dee Wampler Technical Leader

"Wampler, Dee" wrote: > We have upgraded to INFORMIX-4GL Version 7.30.UC1X2 > > We added in one global variable (smallint) to an existing program, compiled > using -shared, and it ran fine > Then we set the variable = 0 and got the following error > dynamic linker: program name: invalid relocation type 72 at 0X0 > killed > > If any other code is added, we get a memory fault core dump > > If we recompile with all the code, using -static, the problem goes away and > the program runs fine > > Any ideas? > A guess. You added the one variable, uninitialized, to the GLOBALS file and only recompiled the one module that used the new variable, right? And that worked until you initialized the variable, still only recompiling only the one module, correct? After that the program crashes until you recompiled every module? Makes perfect sense to me! Uninitialized variables are created at runtime and are appended to the address space of the program. However, initialized variables are created at compile time and the initialized data space is lower in memory. Adding a variable that is initialized will cause the addresses of other variables, and perhaps offsets calculated from one to another, to shift. This means that the other modules code became invalid. I strongly suggest you start using make to manage your 4GL compiles and include dependencies on the GLOBALS file for every module's object file. Then you will not have to deal with the confusion again. This is what make is for. Art S. Kagel

Did you ensure that all of your shared object files were correctly recreated? I ran into a similar problem several years ago. What was happening was that we were picking up a .so that we didn't mean to and were resolving global variables incorrectly. "Wampler, Dee" wrote: > We have upgraded to INFORMIX-4GL Version 7.30.UC1X2 > > We added in one global variable (smallint) to an existing program, compiled > using -shared, and it ran fine > Then we set the variable = 0 and got the following error > dynamic linker: program name: invalid relocation type 72 at 0X0 > killed > > If any other code is added, we get a memory fault core dump > > If we recompile with all the code, using -static, the problem goes away and > the program runs fine > > Any ideas? > > Dee Wampler > Technical Leader

Dee, I am not that familar with SCO. You might want to check to see if they have anything similar to the solaris truss. On some machines this would be trace. Basically what this does is to display all of the system calls made by the executable. Chances are that you have a mismatch between some of the shared objects in your system and that is causing boundry problems (i.e. stuff that is supposed to be on a word boundry is on a half word). By examining the output of a truss-like utility, you can see exactly what shared library objects were loaded by the executable. "Wampler, Dee" wrote: > We have upgraded to INFORMIX-4GL Version 7.30.UC1X2 > > We added in one global variable (smallint) to an existing program, compiled > using -shared, and it ran fine > Then we set the variable = 0 and got the following error > dynamic linker: program name: invalid relocation type 72 at 0X0 > killed > > If any other code is added, we get a memory fault core dump > > If we recompile with all the code, using -static, the problem goes away and > the program runs fine > > Any ideas? > > Dee Wampler > Technical Leader