[SOLVED] Two programs and a file: a logical conundrum

[hazel]

I am working on a program called writemusic that creates a file of structures representing musical glyphs (notes, rests, barlines, etc). Another program called Printmusic then reads this file and writes out the music as a PNG image which can be printed. I had noticed that the final barline was always duplicated and I wanted to know which program was resonsible, so I tried some experiments:

1). I created a file in writemusic and ran it through printmusic, leaving writemusic running. As I expected there were two barlines at the end. I went back to writemusic and added a couple of bars. Now the duplicate barline had vanished to reappear at the new end.

2) I created two files and concatenated them with cat. When I processed this composite file with printmusic, each of the two sections ended with a double barline.

3) I created a file with writemusic, closed the program, relaunched it and reloaded the same file (writemusic allows you to do this). Then I added a few bars. When printmusic had processed this augmented file, there were three barlines at the end of the first section and two at the end of the second.

The results for 2) and 3) only make sense if writemusic is actually putting these duplicates into the file, but the result for 1) suggests that printmusic is doing it when the file is read back.

Can anyone explain this?

[Kloschüssel]

I would examine the data produced by "Writemusic" to determine if the data generated is correct. If that holds, the problem must be in the "Printmusic" program. If the data generated isn't correct, fix the "Writemusic" and re-do the test. If then "Printmusic" has still a error, fix that program too.

[Rubberman]

Can you post the source for these applications here?

[hazel]

I would examine the data produced by "Writemusic" to determine if the data generated is correct. If that holds, the problem must be in the "Printmusic" program. If the data generated isn't correct, fix the "Writemusic" and re-do the test. If then "Printmusic" has still a error, fix that program too.

Since it's a binary file, there's no way to examine the data in it except to read the structures successively in a loop like printmusic does. In other words a program to examine the file would have to use the same logic as printmusic and of course it would give the same result. That's why I tried to find out by using deductive methods.

@rubberman
Here is a zipped package. Printmusic is a single program. The most relevant file in the writemusic bundle is probably storage.c

[Rubberman]

Thanks. I'll take a look when I have a few minutes to analyze it.

[hazel]

Got it! Not the actual bug but I know now where it must be and a few diagnostic debug messages should track it down. (FYI Rubberman, it's the datacopy function in storage.c). The answer to my conundrum is that data entered into writemusic is stored in a temporary file and then transferred to the permanent file when you click on "Save". At present this is done by completely overwriting the permanent file (very inefficient and I shall change it to an append operation) which explains the answer to experiment 1: the old double barline disappears because it gets overwritten.

Isn't it funny how when you have a really tricky problem and you lay it out for someone else, it suddenly becomes clear. Thanks for listening, guys!

[hazel]

Actually there were two bugs, both due to ignorance. First I assumed that feof would be set as soon as the last record was read. It isn't; it only gets set when you try to read beyond the last record. Since my read loop is controlled by feof, that meant one failed read before the change in feof ended the loop. Secondly I thought that fread would return -1 or EOF on failure like most C library functions do. It doesn't; it always returns the number of items read (in this case zero). So the failed read wasn't picked up and the following write operation proceeded as normal - with the previous glyph values, as no new ones had been read.

Bah! That's what happens when you don't RTFM carefully enough.