RE: memory fault, core dump
A user upgrading to INFORMIX-4GL 7.30.UC1X2 found that adding and initializing a global SMALLINT caused "dynamic linker: invalid relocation type 72 at 0X0" and then memory fault/core dumps; even a trivial program calling a function crashed. Compiling with -static, or with the older 7.20.UD6 tools, worked, pointing at the -shared/dynamic linking path. Art Kagel suggested stale objects from partial recompiles (fixed by make with GLOBALS dependencies), but the poster had already used make. David Williams asked about platform, C compiler and PATH; no answer or resolution is recorded, and the thread drifts into Oracle/QueriX 4GL marketing chatter.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
We did use make and recompiled all of the modules at the same time. When the variable was just in the globals.4gl, and the program was compiled using make, it was fine. When the "LET g_item = 0 " was added and the program compiled with make, we got dynamic linker: program name: invalid relocation type 72 at 0X0 killed If any other code was added to the program using the variable, we get a memory fault, core dump. If we compile in INFORMIX-4GL Version 7.20.UD6 , any additions work fine. If we compile in 730 using the static option, any additions work fine. Seems as though the shared option may be the problem. We have had problems with the 730 tools getting a memory fault core dump problem in various programs Example: main call dis_call() end main function dis_call() display "craptest" sleep 5 end function This gets a memory fault core dump main display "craptest" sleep 5 end main this works fine Any suggestions? Dee Wampler Technical Leader > -----Original Message----- > From: Art S. Kagel [SMTP:kagel@bloomberg.net] > Sent: Friday, May 12, 2000 9:57 AM > To: informix-list@iiug.org > Subject: Re: memory fault, core dump > > "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 >
In article <8fhch5$sfo$1@news.xmission.com>, Wampler, Dee <wampled@hastings-ent.com> writes > >We have had problems with the 730 tools getting a memory fault core dump >problem in various programs > >Example: >main >call dis_call() >end main >function dis_call() >display "craptest" >sleep 5 >end function Which platform are you running on ? Which C compiler and what is your PATH set to? >This gets a memory fault core dump > >main >display "craptest" >sleep 5 >end main > >this works fine > >Any suggestions? > >Dee Wampler >Technical Leader > >> -----Original Message----- >> From: Art S. Kagel [SMTP:kagel@bloomberg.net] >> Sent: Friday, May 12, 2000 9:57 AM >> To: informix-list@iiug.org >> Subject: Re: memory fault, core dump >> >> "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 >> -- David Williams
Oh dear Oh dear Oh dear .......
On Sun, 14 May 2000 22:03:18 +0100, DNP Wrote: > Oh dear Oh dear Oh dear ....... I dont believe that Oracle even has a product equivalent to I4GL and if it did it would be subject to the same problems that any compiled program has with respect to restrictions on the use of memory that the OS might impose. /J\\
Jonathan Stowe wrote: > On Sun, 14 May 2000 22:03:18 +0100, DNP Wrote: > > Oh dear Oh dear Oh dear ....... > > I dont believe that Oracle even has a product equivalent to I4GL and if it > did it would be subject to the same problems that any compiled program has > with respect to restrictions on the use of memory that the OS might impose. > > /J\\ May not have had but now a days you can use exactly the same syntax on Oracle, all you have to do is to recompile the code using the right compiler. As for the restrictions on the memory all you have to take care of is to initialize the variables you use. (You may also use a compiler flag which would do the job for you. -- Compliments of QueriX -------------------------------------------------------------------------------------------------- QueriX 4GL Compilers are Informix 4GL Compatible, and Connection to other RDBMS such as Oracle. Hydra 4GL Compiler (Compatible with I4GL) Compile once, run everywhere Phoenix Windows GUI. (Front End to 4GL) Chimera Java GUI The only GUI you will ever need... (Front End to 4GL) Arachne Web Technology (Front End to 4GL on the Web & HTML Report Generator) ESQL/C Compiler For more details visit: http://www.querix.com/ ---------------------------------------------------------------------------------------------------