C Code Failing on an "fgets" Call

[Spab23]

I am in the process of porting some code from an AIX 4.3.3 box (F50 - 32 bit machine) running C 5.0.1 onto an AIX 5.2 box (p630 - 64 bit machine) running C 5.0.2.

For some reason the code fails on an fgets call in the conditional statement of a while loop, but ONLY when a certain function is called within the loop.

Here's how it's set up:

#define MAX_INBUF 1024

while (fgets(inbuf, MAX_INBUF, templateFile) != NULL) {
   if a certain piece of text is contained within "inbuf"
      call a function
   the function returns okay (I've tested that)
   but the next time "fgets" is called, it fails.
}

I'm resisting posting the actual code here because it involves a lot of subroutines and data structures, which makes it quite lengthy. I know (from debugging statements I've added) that the program returns from the function call and the file status is still open. (The function does open another FILE pointer and closes it, but I checked the address of the pointer and it's different.)

Can anyone offer any help, or is this example too generalized?

 

[Salem]

I'm assuming that
char inbuf[MAX_INBUF];
is your input array.

From what you've said, this loop is not the problem. The problem with most memory corruption problems is that cause and effect are separate. This makes tracking them down somewhat tricky.

Personally, I would start looking at the called function which triggers the problem in this loop. Examine it closely, and consider commenting out parts of the functionality to see if that changes the fault behaviour.

> or is this example too generalized?
Debug at a distance is too tricky really. Specific bits of code which can be compiled and run are the best to work with.

 

[Spab23]

Yes, Salem... your assumption that "char inbuf[MAX_INBUF];" is my input array is correct. I forgot to include that in my code snippet.

I am definitely taking a hard look at the function, believe me. Thanks for your suggestions. I am currently attempting to compile and run parts of the code to attempt to see where the problem lies.

 

[dlkfjdlkfjdlfkd]

I'm afraid it's too generalized. You should try to cut your code down to the smallest, compilable example that demonstrates the problem. This process, while probably painful, might reveal the problem.

It seems likely that the function you're calling is doing something that you don't realize. For instance, it could be writing into memory you don't own and corrupting the file structure you're calling fgets on.

 

[Spab23]

I tried using dbx to debug it and I've gotten the following stack traces:

global_lock_ppc_mp() at 0xd0063ac4
_rec_mutex_lock(??) at 0xd01ddaa0
fgets(??, ??, ??) at 0xd01e04a0
MakeForm(form = "sub_menu2", dataPtr = 0x2ff21fc8), line 252 in "make_form.c"
main(argc = 1, argv = 0x2ff22060), line 315 in "do_action.c"

and

global_lock_ppc_mp() at 0xd0063ad4
_rec_mutex_lock(??) at 0xd01ddaa0
fgets(??, ??, ??) at 0xd01e04a0
MakeForm (form = "main_menu", dataPtr = 0x2ff21ff8), line 251 in "make_form.c"
main(argc = 1, argv = 0x2ff22094), line 231 in "login.c"

These two stack traces are for two different routines, both of which call the MakeForm routine. Is there anything here that can help me? I'm concerned about the ?? in the fgets call. The line number difference between the two failures is caused by me adding more debugging code between the two executions. They are both failing on the same line. (The

fgets(inbuf...

call I posted earlier.)

 

[Salem]

> Is there anything here that can help me?
It doesn't look hopeful

> I'm concerned about the ?? in the fgets call.
It just means there is less debug information in the library. You may have a debug version of 'libc', but that would require a bit more digging around in your compiler options to make it use it.

All it knows about is the name of the function and the fact that it has 3 parameters (no name/type information). The location is printed as a hex address (rather than line number/filename)

In your code, the debugger has name/type information, as well as line number and filename information, so its able to give you more details.

Do you use malloc()/free() a lot in your code?

If so, consider this (or similar tools)

http://perens.com/FreeSoftware/

Look at the electric fence.

 

[Spab23]

Yes, there are a lot of malloc()/free() calls in this program. (I actually didn't write it... I'm debugging someone else's code... *sigh*)

I'll look into that Electric Fence program. Thanks again!