SIGSEGV due to fscanf

[subirs]

Hi,

I am encountering SIGSEGV if I am opeing and closing a file in a
do-while loop. i am including the part of the code where I have used
fscanf.
-----------------------------------------------------------------
FILE *save;
do
{
save=fopen("Settings/iwrite.dat","r");
fscanf(save,"%d",&stop);
fclose(save);
}
while( some condition here)
-----------------------------------------------------------------
The strange part is if I write a sample code just to read a file using
fscanf function it does not give me SIGSEGV no matter for how many
iterations i run the code. I am facing the problem while running the
sequential as well as parallel version of the same code on

Module V 40 Z - Dual Processor (40 CPUs), AMD Opteron 2.4 GHz, 8 GB RAM

using Redhat Linux enterprise.

I have even used file lock to overcome this error but of no use.
What could be the problem ? Any suggestions will be greatly
appreciated.

Thanks
Subir

 

[Ico]

Hi,

I am encountering SIGSEGV if I am opeing and closing a file in a
do-while loop. i am including the part of the code where I have used
fscanf.
-----------------------------------------------------------------
FILE *save;
do
{
save=fopen("Settings/iwrite.dat","r");

You are not checking the return value of fopen() here. If the call fails
for whatever reason, scanf() is very likely to give you problems. Add
proper error handling here, I bet this will solve your problem.

 

[Walter Roberson]

I am encountering SIGSEGV if I am opeing and closing a file in a
do-while loop. i am including the part of the code where I have used
fscanf.
-----------------------------------------------------------------
FILE *save;
do
{
save=fopen("Settings/iwrite.dat","r");
fscanf(save,"%d",&stop);
fclose(save);
}
while( some condition here)

Although the other poster's point about error checking is good,
my -suspicion- is that your problem might not be directly in
the section you indicate. My -guess- is that you have an earlier
memory corruption problem, and that this code just *happens* to
be the first place it makes a difference.

Memory corruption problems can lurk and not show up until much
later in the code, depending on the exact memory allocation
pattern and depending upon the details of the memory allocation
routine.

Memory corruption problems that can lead to the kind of difficulty
I refer to, include:

- writing before the beginning of a dynamically allocated object
- writing past the end of a dynamically allocated object
- free()'ing the same dynamically allocated pointer twice
- writing into any dynamic object after it has been free()'d

All of these can corrupt the way the memory allocator keeps track
of memory, and the problem might not show up until much later.

It is also possible to get the same kinds of effects by writing
before or after the end of objects of automatic scope, but when
that happens it is not uncommon for very minor changes in the
program to alter the problem behaviour, due to the compiler
happening to lay out memory a bit differently for the different code.
A problem that persistantly happens in the same routine is more -likely-
to do with corruption of dynamic objects.

 

[subirs]

Thanks for suggestions.

 

[Al Balmer]

Although the other poster's point about error checking is good,
my -suspicion- is that your problem might not be directly in
the section you indicate. My -guess- is that you have an earlier
memory corruption problem, and that this code just *happens* to
be the first place it makes a difference.

Possible, but should not even be considered until the known problem is
corrected.

When you find a bug, fix it. You may be surprised to find that the
original mysterious problem has disappeared ;-)