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.

Any chance you did something like this:

Code:

---

int x = somefunction();
fwrite(x, ...)

---

rather than

Code:

---

...
fwrite(&x, ...)

---

?

--
Mats

I'm doing something more along the lines of:

Code:

---

FILE *myfile

fopen("myfile", "w");

fprintf(myfile, "data %f", data);

---

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

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.

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.

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.

Quote:

---

Originally Posted by brewbuck

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

Quote:

---

Originally Posted by matsp

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.

Quote:

---

Originally Posted by grumpy

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

Quote:

---

Originally Posted by matsp

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.

Quote:

---

Originally Posted by grumpy

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