Re: ESQL/c problem

Sanjit Chakraborty wrote: > Quick questions about ESQL/C program, hope you can helps :o) > > I have recently upgraded informix from 5.06 to 7.31.uc2. One ESQL/C program > which use to run in > v5.x are not running in new vertion. It's get hung in a 'malloc' function > I have recompile all programs > in new vertion). Can any one tell, what could be the season? Well, when malloc misbehaves, it means there's a bug somewhere in the way the memory it allocates is (mis)used. It isn't so obvious how it is being misused. Do you religiously check the return from (a) every memory allocation and (b) every SQL statement. If not, then one of those unchecked statements is probably causing the trouble. If so, and if you are not trying to free the same memory twice (a definite no-no), then it is going to take time to find out what you're doing wrong. Do you have Purify available to you? If so, use it. Do you have any other debugging malloc()s? If so, use them? If not, contact me (as long as you're on Unix-ish systems) and you can use the one I've got. It might help spot the trouble. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN #include <disclaimer.h>

Jonathan Leffler wrote: > > Sanjit Chakraborty wrote: > > > Quick questions about ESQL/C program, hope you can helps :o) > > > > I have recently upgraded informix from 5.06 to 7.31.uc2. One ESQL/C program > > which use to run in > > v5.x are not running in new vertion. It's get hung in a 'malloc' function > > I have recompile all programs > > in new vertion). Can any one tell, what could be the season? > > Well, when malloc misbehaves, it means there's a bug somewhere in the way the > memory it allocates is (mis)used. It isn't so obvious how it is being > misused. Do > you religiously check the return from (a) every memory allocation and (b) every > SQL > statement. If not, then one of those unchecked statements is probably causing > the > trouble. If so, and if you are not trying to free the same memory twice (a > definite no-no), > then it is going to take time to find out what you're doing wrong. > > Do you have Purify available to you? If so, use it. Do you have any other > debugging malloc()s? > If so, use them? If not, contact me (as long as you're on Unix-ish systems) > and you can use the > one I've got. It might help spot the trouble. Similarly, someone once brought me a program that was crashing saying "Informix isn't working" <sigh>. I found a function call that free()d one of its arguments, a string pointer. Looking back I found a call to that function with an automatic char array passed in for the argument that was to be free()d, a definite no-no (not that freeing a pointer in a function other than the one in which it was allocated is too bright to begin with). The programmer said: "But I inherited it and it's been running for two years like this, and it works! Are you SURE it's not the new ESQL version?" I won't post my response. Needless to say fixing the errant code solved the crashing problem. Another one. Recently a programmer brought a problem: "It's crashing just like the last one I think it's another library problem with that new DG lib." Debugging I got down to the fatal function call and checked all the args, entered the function and walked through it, stepping over a lower level call for now, and popped back to the calling function. Not only was the result what the function thought it had returned, the arguments had the wrong values, and their addresses had CHANGED! AHA that lower level function had overflowed an automatic array (strcpy from a string with no null terminator) and trashed the stack. "But it never crashed before and all I did was add a printf two levels above!", the programmer said. Obviously the array's position on the stack has changed and what was harmless before was deadly now. Take a lesson. The compiler version swap may just be revealing old source problems that just did not cause grief before because the generated code was different or there were no shared libraries before so the stack and heap were abutted or who knows what. Art S. Kagel

In article <385FDB02.C50260EF@bloomberg.net>, Art S. Kagel <kagel@bloomberg.net> writes > >Take a lesson. The compiler version swap may just be revealing old source >problems that just did not cause grief before because the generated code was >different or there were no shared libraries before so the stack and heap >were abutted or who knows what. > a) Run automated tests b) use two compilers c) Turn on ALL warns + make warnings errors. >Art S. Kagel -- David Williams