Simple write to a file causing seg-fault??

This is a discussion on Simple write to a file causing seg-fault?? within the C Programming forums, part of the General Programming Boards category; This is driving me insane!! I have a program that works absolutely fine. I'd like some benchmarks on the program, ...

  1. #1
    PhysicistTurnedProgrammer Cell's Avatar
    Join Date
    Jan 2009
    Location
    New Jersey
    Posts
    72

    Simple write to a file causing seg-fault??

    This is driving me insane!!

    I have a program that works absolutely fine. I'd like some benchmarks on the program, so I added some timing code and I've been trying to write that data plus a few other pieces of information to a file. In the middle of my program's execution it suddenly exits with a segmentation fault error. It also says "Address is not mapped".

    I write to plenty of other files throughout the course of the program, but for some reason these benchmarks cause a program.

    Can you guys think of a generic reason why this could be occurring? Could I be trying to write too much data to the file and it's running out of memory?

    Thanks.

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Any chance you did something like this:
    Code:
    int x = somefunction();
    fwrite(x, ...)
    rather than
    Code:
    ...
    fwrite(&x, ...)
    ?

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    PhysicistTurnedProgrammer Cell's Avatar
    Join Date
    Jan 2009
    Location
    New Jersey
    Posts
    72
    I'm doing something more along the lines of:

    Code:
    FILE *myfile
    
    fopen("myfile", "w");
    
    fprintf(myfile, "data %f", data);

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    And I suppose myfile actually DOES open correcetly, and you haven't mistakenly used a = instead of == when checking if the file DID open?

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    PhysicistTurnedProgrammer Cell's Avatar
    Join Date
    Jan 2009
    Location
    New Jersey
    Posts
    72
    Yeah the file opens correctly and I've inserted random fprintf statements in various areas of the code to determine that the opening of and writing to the file is working correctly.

    I've also physically deleted the file, run the program, and it recreates the file and prints the test strings inside.

  6. #6
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Make the smallest working example you can. If it works, then you're probably trashing your memory some place.
    Code:
    #include<stdio.h>
    int main( void )
    {
        FILE *fp = fopen( "foo.bar", "w" );
        if( fp )
        {
            fprintf( fp, "this is a test of the emergency broadcast system\n" );
            fclose( fp );
        }
        return 0;
    }
    If that doesn't work fine... I don't know. Maybe you have a permissions issue some place. Though to be honest, it shouldn't create the file if you don't have permissions to that folder, so I'm not sure what it would be if your simplest example doesn't work.

    Quzah.
    Hope is the first step on the road to disappointment.

  7. #7
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    If your code crashes, it is NOT correct.

    More than likely, you are trashing memory somewhere, and the random code jitter caused by inserting your I/O statements is revealing that issue. Correct code doesn't crash just because you insert more correct code.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by brewbuck View Post
    If your code crashes, it is NOT correct.

    More than likely, you are trashing memory somewhere, and the random code jitter caused by inserting your I/O statements is revealing that issue. Correct code doesn't crash just because you insert more correct code.
    Unless of course the compiler is complete and utter garbage! But if it is GCC or MS Visual Studio, then we can rule that one out too.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Registered User
    Join Date
    Jun 2005
    Posts
    6,301
    Quote Originally Posted by matsp View Post
    Unless of course the compiler is complete and utter garbage! But if it is GCC or MS Visual Studio, then we can rule that one out too.
    That's not true. Brewbuck's observation is correct, regardless of whether the code is compiled with high or low quality compilers.

    One moderately common symptom of pointer molestation is that the observed behaviour can change by adding or removing unrelated new code - simply because the offending pointer molestation affects some area of memory, and inserting or removing unrelated code can simply changes what, precisely, is in that area of memory.

    People often assume that, if a symptom disappears when some section of code is removed, that the cause is in that code. Unfortunately, that assumption is not always true.
    Right 98% of the time, and don't care about the other 3%.

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by grumpy View Post
    That's not true. Brewbuck's observation is correct, regardless of whether the code is compiled with high or low quality compilers.

    One moderately common symptom of pointer molestation is that the observed behaviour can change by adding or removing unrelated new code - simply because the offending pointer molestation affects some area of memory, and inserting or removing unrelated code can simply changes what, precisely, is in that area of memory.

    People often assume that, if a symptom disappears when some section of code is removed, that the cause is in that code. Unfortunately, that assumption is not always true.
    I have actually used a compiler (very briefly) that, when given correct source code (no undefined behavior or otherwise incorrectly behaving code) produced instructions that caused a crash - it simply produced BAD instructions (instead of using the register containing the address of the operand, it produced a fixed address that was not even mapped in the system - presumably CAUSED by some bad code in the compiler itself. And this wasn't just an experimental compiler either, it was an Intel compiler from Intel's website (but I was pushing the envelope a bit by using the highest optimization and SSE code generation, which I expect may have been what triggered the problem).

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #11
    Registered User
    Join Date
    Jun 2005
    Posts
    6,301
    Quote Originally Posted by matsp View Post
    I have actually used a compiler (very briefly) that, when given correct source code (no undefined behavior or otherwise incorrectly behaving code) produced instructions that caused a crash - it simply produced BAD instructions (instead of using the register containing the address of the operand, it produced a fixed address that was not even mapped in the system - presumably CAUSED by some bad code in the compiler itself. And this wasn't just an experimental compiler either, it was an Intel compiler from Intel's website (but I was pushing the envelope a bit by using the highest optimization and SSE code generation, which I expect may have been what triggered the problem).
    Maybe so, but I doubt that's what Brewbuck was referring to. I've also encountered my share of compiler bugs, including an internal error - duly reported - in the lastest gcc, and I'm confident other members here will have too.

    However, the most common explanation of "add/remove code, strange symptom changed" is a coding error rather than a compiler error.
    Right 98% of the time, and don't care about the other 3%.

  12. #12
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by grumpy View Post
    However, the most common explanation of "add/remove code, strange symptom changed" is a coding error rather than a compiler error.
    Absolutely - the proportion of compiler bugs vs. coding bugs in my code is probably > 10000:1. [Occassionally, I've had both - that is, a compiler bug caused by incorrect code, e.g syntax error leads to compiler crash rather than the appropriate error message].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Formatting the contents of a text file
    By dagorsul in forum C++ Programming
    Replies: 2
    Last Post: 04-29-2008, 12:36 PM
  2. Seg Fault -- Plz Help Quick
    By djwicks in forum C Programming
    Replies: 1
    Last Post: 04-10-2005, 09:08 AM
  3. Simple File encryption
    By caroundw5h in forum C Programming
    Replies: 2
    Last Post: 10-13-2004, 10:51 PM
  4. lsass is causing a seg fault
    By skorman00 in forum Tech Board
    Replies: 3
    Last Post: 07-02-2004, 09:33 PM
  5. Simple File Creation Algorithm
    By muffin in forum C Programming
    Replies: 13
    Last Post: 08-24-2001, 03:28 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21