@MSGID: 1@dont-email.me> 18976005
@REPLY: 1@dont-email.me> f56398d4
@REPLYADDR Rich <rich@example.invalid>
@REPLYTO 2:5075/128 Rich
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
<ygamsxoixhx.fsf@akutech.de> 4@dont-email.me> <ygail8biyxm.fsf@akutech.de>
1@dont-email.me> <ygaedizitb9.fsf@akutech.de> 2@dont-email.me>
<yga4jjvik9o.fsf@akutech.de> 1@dont-email.me>
@TZUTC: -0000
@PID: tin/2.6.1-20211226 ("Convalmore")
(Linux/5.15.117 (x86_64))
@TID: FIDOGATE-5.12-ge4e8b94
In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 15/09/2023 15:27, Ralf Fassel wrote:
>> Note that the assignment
>> 
>>    thermometers[i].name=strdup(p);
>> 
>> is *inside* the while() loop without a free().
>> 
>> Probably you argue that there ever is only a single file to read in 
>> that dir anyway...  Personally, I`ve been bitten by such 
>> assumptions, so I`d rather check once too often than hunting down 
>> "can`t happen" bugs.
>> 
> I do think that what has happened is that a valid file name has been 
> found with empty data, or no file at all, and then no strdup is done 
> - but the free is, next time around.
> 
> That should never happen of course, as the fopen/fwrite sequence 
> should certainly not delete the filename, but it is entirely possible 
> that a the fopen *truncates* its data.  At which point we cant strdup 
> anything, so the next free gets a woopsie

Are the "files" being written to by an independent process separate 
from this reading process?

If yes, are you doing any form of locking/synchronization to prevent 
the reading process from trying to read from a file that a writing 
process has open/truncated, but not yet written any data into?

If no, then you may be also hitting a race condition where the stars 
align just right, the writer has just performed its fopen/truncate 
(leaving the file empty) and the kernel decides to context switch away 
to the reader at that point, before the writer can write and close the 
file.  The reader will then see an empty file.

The classic "lock free" solution to this one is for the writer to 
create and write to a temporary file, and after closing the temp file 
to rename() it to the name of the real file.  Rename is documented to 
be atomic, so the reader would never see a half open, or partially 
complete, file in this case.
--- tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.117 (x86_64))
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441