This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Expected behavior?


Hi all,

Taking up this email that I sent almost two months ago, I have found out that there is a "bug" in my code. The bug is that I use "w+" to write to the second file (which is the output file of my program). Since "w+" (and "w") truncates the file, if several processes open the file at the same time, a process can delete the information previously written by another process. I tried several open modes without success, and I probably left that option without noticing.

But, and here is the funny part, if I want the program to work properly, the output file must exist and must be opened with "r+". This is counterintuitive because I just want to write to the file, I do not want to read it. As I have said, "w" and "w+" truncate the file and they are not valid options for my program. But "a" and "a+" are not valid options either. The problem is now that "fseek" does not work with these "fopen" modes. How is it supposed that I must know that? I have not seen any information about this problem either in the manual pages or info entries of fseek and fopen. Moreover, fseek does not fail and returns 0. I know that, with "a" and "a+", output is written at the end of the file but, frankly, I assumed that this was the default behavior that you could change with fseek. Obviously, I was wrong.

I think that a clarification about this issue in the documentation of fseek would be appreciated.

Regards,

Juan.

Juan Piernas Canovas wrote:
Hi all,

Before submitting a bug, I would like to know if the following is an expected behavior. I have written a small program (attached) which basically multiplies a set of doubles stored in an input file by a scalar, and saves the resulting doubles in an output file. As arguments, the user has to specify an offset and a size. The offset is the starting point in both the input and output files, and the size says how many bytes to read from the input file, and write to the output file. Obviously, if the output file is empty and the offset is not equal 0, we will be creating a sparse file.

I have also attached a script which runs the program twice by creating two processes at the same time. Both processes use the same input and output files, and receive the same scalar and size values, but different offsets. With the give parameters, the processes read and write different "disjoint" portions of the input and output files. Note that the output file will be a sparse one because the processes leave "holes" in the file. The script also checks whether the content of the output file is correct or not.

The problem that I'm having is that the output file is not created correctly, and I am pretty sure that the problem is in the fwrite function. The first doubles (in an indefinite amount) written by sometimes the first process, sometimes the second, and sometimes both processes, are always 0.0, what seems to mean that there is a hole where there should not be. That occurs randomly.

Please, note that we are talking about independent processes which must not share any information about the file (such as the file pointer).

Does anyone have any clue about what is happening?

BTW, I do not have any problem if I use the "low-level" open, read, write and close functions. And I have got the problem in three different Linux distributions (SLES 10.2-sp1, RHEL 4, Fedora Core 6) with different glibc versions.

Thanks in advance,

Juan.

PS. I can send the input file if needed, but it does not contains anything special, just random numbers.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]