What's wrong with my fseek() ?

[barramundi9]

Dear all:

Below will only print to Record #49 and encounters segmentation fault, I found that if I take the second fseek() off, everything works fine, can anyone enlighten me as to why the second fseek() won't work, thanks

#include <unistd.h>
#include <stdio.h>
#include <sys/mman.h>
#include <fcntl.h>

typedef struct {
	int integer;
	char string[12];
} RECORD;

#define NRECORDS (50)

int main () {

	RECORD record;
	int i;
	FILE *fp;

	fp = fopen("records.dat", "w+");
	for (i=0; i<NRECORDS; i++) {
		record.integer = i;
		sprintf(record.string, "RECORD - %d", i);
		fprintf(stdout, "RECORD - %d\n", i);
		fwrite(&record, sizeof(record), 1, fp);
	}

	fclose(fp);

	fp = fopen("records.dat", "w+");

	fseek(fp, 43*sizeof(record), SEEK_SET);
	fread(&record, sizeof(record), 1, fp);

	record.integer = 999;
	sprintf(record.string, "RECORD - %d\n", record.integer);

	fseek(fp, 43*sizeof(record), SEEK_SET);
        // it dies here

	printf("after setting to 999 \n");
	fwrite(&record, sizeof(record), 1, fp);

	fclose(fp);
	return 0;
}

[CommonTater]

It only goes to 49 because you initialized the file to 50 elements... which like arrays are numbered 0 to 49.
When you try to read #50, you are reading beyond the end of the file and it's going to error off.

Also you have a problem with your sprintf() immediately above where you marked. You have not allocated enough space for record.string. As it is, you have room only for a single digit number before it overflows. Try expanding it to 20 or more characters. (A bit of slack space is less of a problem than not having enough.)

Finally, you should take the \n out of your sprintf()s. If you want newlines, do that at display time.

[barramundi9]

Thanks for the reply.

The funny thing is, I put the exactly same code on Suse Linux 64 bit server, it executes fine, but it complains about segmentation fault when I execute in Ubuntu 11.04

Any ideas?

Thanks

It only goes to 49 because you initialized the file to 50 elements... which like arrays are numbered 0 to 49.
When you try to read #50, you are reading beyond the end of the file and it's going to error off.

Also you have a problem with your sprintf() immediately above where you marked. You have not allocated enough space for record.string. As it is, you have room only for a single digit number before it overflows. Try expanding it to 20 or more characters. (A bit of slack space is less of a problem than not having enough.)

Finally, you should take the \n out of your sprintf()s. If you want newlines, do that at display time.

[TheBigH]

The funny thing is, I put the exactly same code on Suse Linux 64 bit server, it executes fine, but it complains about segmentation fault when I execute in Ubuntu 11.04

Segfaults are evil like that. You get segfaults when you try to touch memory that's already allocated to something else. If you make a mistake and you're lucky you'll get a segfault. If you're unlucky your attempt to access memory you have no right to will end up accessing memory not allocated to anything and the program will run, possibly spouting a whole lot of gibberish nonsense results based on the random leftovers there.

Frequently segfaults turn up far away from where your actual coding error was, which is highly frustrating and leads you to point an accusing finger at perfectly blameless code.

I hate segfaults.

[barramundi9]

Well, I tried your suggestion on expanding the number of the character array element to 20 and it worked on Ubuntu as well ...

Thanks.

Thanks for the reply.

The funny thing is, I put the exactly same code on Suse Linux 64 bit server, it executes fine, but it complains about segmentation fault when I execute in Ubuntu 11.04

Any ideas?

Thanks

[Salem]

> The funny thing is, I put the exactly same code on Suse Linux 64 bit server, it executes fine, but it complains about
> segmentation fault when I execute in Ubuntu 11.04
> Any ideas?
Yes, exactly for the reason that CommonTater said.
You overwrote the end of an array.

The thing you have to remember is that as soon as you do something bad, absolutely ANYTHING can happen, which specifically includes "doing exactly what I expect". This is unfortunate, since you suddenly believe your program is bug free (when it isn't).
It's only when you do something different (add more code, try another file, try another system) that it all breaks down.

Try
valgrind myprog
and see what it reports as well.
I've posted several times on how to analyse valgrind output, look for it.