SIGSEGV due to fscanf

Discussion in 'C Programming' started by subirs, May 21, 2006.

  1. subirs

    subirs Guest

    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
     
    subirs, May 21, 2006
    #1
    1. Advertising

  2. subirs

    Ico Guest

    subirs <> wrote:
    > 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.

    > 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
    >


    --
    :wq
    ^X^Cy^K^X^C^C^C^C
     
    Ico, May 21, 2006
    #2
    1. Advertising

  3. In article <>,
    subirs <> wrote:
    > 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.


    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.
    --
    "No one has the right to destroy another person's belief by
    demanding empirical evidence." -- Ann Landers
     
    Walter Roberson, May 22, 2006
    #3
  4. subirs

    subirs Guest

    Thanks for suggestions.
     
    subirs, May 22, 2006
    #4
  5. subirs

    Al Balmer Guest

    On Mon, 22 May 2006 06:35:05 +0000 (UTC), -cnrc.gc.ca
    (Walter Roberson) wrote:

    >In article <>,
    >subirs <> wrote:
    >> 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.

    >
    >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 ;-)

    --
    Al Balmer
    Sun City, AZ
     
    Al Balmer, May 22, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Frank
    Replies:
    0
    Views:
    2,146
    Frank
    Aug 5, 2003
  2. manoj
    Replies:
    0
    Views:
    1,209
    manoj
    Jun 25, 2004
  3. Morris Dovey

    gdb SIGSEGV

    Morris Dovey, Feb 12, 2004, in forum: C Programming
    Replies:
    3
    Views:
    1,037
    Mark McIntyre
    Feb 14, 2004
  4. Nancy
    Replies:
    0
    Views:
    337
    Nancy
    Apr 5, 2006
  5. Fresh
    Replies:
    2
    Views:
    663
    Bo Persson
    Apr 22, 2008
Loading...

Share This Page