0

EDIT: It works when I change the working directory, thus the files are created in a different directory. The only odd thing about the directory I was using previously was that it is a shared directory used with VirtualBox. Is this a VirtualBox bug all along? I better start using a separate directory.

I've got an extremely weird problem. Somewhere in my program I have this code. I've modified it to print out some information to demonstrate the problem:

uint8_t section[9]; long pos = ftell(rd); fseek(rd, 0, SEEK_END); printf("%li\n",ftell(rd)); fseek(rd, pos, SEEK_SET); printf("%li\n",ftell(rd)); clearerr(rd); int i = fread(section, 1, 9, rd); if (i != 9){ printf("%i - %i - %i\n",i,feof(rd),ferror(rd));

The output is this:

23 14 0 - 0 - 1

So the length of the file at this point is 23 and the cursor is at 14. I want 9 bytes but fread gives zero and presents an error. I get this problem with Linux Mint and not on OSX. Someone else does not seem to have this problem on debian. I have no idea what could cause this problem. Is there no way to diagnose the cause of the error further? ferror() gives zero information.

The file is opened with the "wb+" mode.

Edit:

I found this obscure error with valgrind:

==22141== Syscall param write(buf) points to uninitialised byte(s) ==22141== at 0x5B68900: __write_nocancel (syscall-template.S:82) ==22141== by 0x5AFB882: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1289) ==22141== by 0x5AFB749: new_do_write (fileops.c:543) ==22141== by 0x5AFCEB4: _IO_do_write@@GLIBC_2.2.5 (fileops.c:516) ==22141== by 0x5AFDD3E: _IO_switch_to_get_mode (genops.c:189) ==22141== by 0x5AFBA96: _IO_file_seekoff@@GLIBC_2.2.5 (fileops.c:999) ==22141== by 0x5AF4F25: rewind (rewind.c:37) ==22141== by 0x567D149: CBFileAppend (CBFileEC.c:69) ==22141== by 0x5473AFA: CBDatabaseCreateDeletionIndex (CBDatabase.c:270) ==22141== by 0x5473195: CBInitDatabase (CBDatabase.c:112) ==22141== by 0x54721A1: CBNewAddressStorage (CBAddressStorage.c:37) ==22141== by 0x401F67: main (testCBAddressManager.c:226) ==22141== Address 0x402a009 is not stack'd, malloc'd or (recently) free'd ==22141== Uninitialised value was created by a stack allocation ==22141== at 0x546F750: ??? (in /media/sf_BitEagle_Projects/cbitcoin/bin/libcbitcoin-storage.2.0.so)

I don't know where ??? is obviously, so I have no luck in debugging this further. It's odd as it's complaining in rewind().

Thanks.

Improve this question
17
  • Not sure it'll change, but I'd do fread(section, 9, 1, rd)... Commented Feb 3, 2013 at 18:26
  • What about the definition of section? Maybe there is a buffer overflow. Commented Feb 3, 2013 at 18:31
  • I thought errno was not set on a read error? Commented Feb 3, 2013 at 18:35
  • I'll try fread(section, 9, 1, rd) because you never know. Commented Feb 3, 2013 at 18:35
  • Hmm maybe the wb+ access: from the man page w+ Open for reading and writing. The file is created if it does not exist, otherwise it is truncated. The file is truncated probably - Did you try with r+ access (or rb+)? Commented Feb 3, 2013 at 18:38

2 Answers 2

Reset to default
2

"wb+" destroys the contents of an existing file, according the to the docs: http://en.cppreference.com/w/c/io/fopen. When you attempt to use "rb+", you must first recreate the file or you'll appear to have the same problem as if you had opened it with "wb+" for that invocation.

EDIT: Is this what your full example code looks like?

int main() { typedef unsigned char uint8_t; FILE * rd = fopen("foo.tmp", "wb+"); uint8_t section[9] = {0}; long pos = 0; fprintf(rd, "01234567890123456789012"); fseek(rd, 14, SEEK_SET); pos = ftell(rd); fseek(rd, 0, SEEK_END); printf("%li\n",ftell(rd)); fseek(rd, pos, SEEK_SET); printf("%li\n",ftell(rd)); clearerr(rd); int i = fread(section, 1, 9, rd); if (i != 9){ printf("%i - %i - %i\n",i,feof(rd),ferror(rd)); } return 0; }
Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

I realise "wb+" destroys the contents of the file. This is precisely what I intend (or I'd use "rb+"). I write data to the file after opening it. Then I read this data at a later time. So I fail to see the problem here.
My full code is this but without the printf()'s: github.com/MatthewLM/cbitcoin/blob/master/test/… That is the file with main() but there are many more files involved. It doesn't resemble your example I'm afraid. The problem code is at: github.com/MatthewLM/cbitcoin/blob/master/dependencies/storage/…
Though when I think about it, I guess your example generates the same type of conditions.
Hm, well it's difficult for me to say in that case. Your CBFileSeek() function looks a little odd at first glance. Particularly, the offset logic which seems to be attempting to convert from bit length to byte length.
My IO code abstracts hamming code error correction and detection. I have a feeling now that the error is caused by heap corruption since I have some uninitialised value problems.
0

You probably wont believe this but it was indeed a problem with VirtualBox and the shared directory. The build process works fine on a normal directory. Thanks to everyone that tried to help. I've not used strace before but I'll keep that one in mind! And I did get strace-plus to work in the end which might prove useful someday.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.