@MSGID: 2@dont-email.me> 4ff21aa6
@REPLY: 1@dont-email.me> 18976005
@REPLYADDR The Natural Philosopher
<tnp@invalid.invalid>
@REPLYTO 2:5075/128 The Natural Philosopher
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 2@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> 1@dont-email.me>
@TZUTC: 0100
@PID: Mozilla/5.0 (X11; Linux x86_64; rv:102.0)
Gecko/20100101 Thunderbird/102.15.1
@TID: FIDOGATE-5.12-ge4e8b94
On 15/09/2023 16:26, Rich wrote:
> 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?
> 
Yes

> 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?
> 
No.

> 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.
> 
I think that is exactly the case. I didnt think that was in fact possible

> 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.

Yes, I was just wondering that before I read this post. Rename unlinks 
the old file does it?

I might implement that, as well.  It doesn`t really matter however, as 
in practice the structures than contain thermometer data don`t get 
altered if no valid data is found, so the lack of a proper file, ex of 
causing a crash, now simply means the (unused in this program) name data 
gets erased. For a few seconds. It simply misses a reading and uses last 
times data for everything else. Mostly the temperature.




-- 
Truth welcomes investigation because truth knows investigation will lead 
to converts. It is deception that uses all the other techniques.

 --- Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.15.1
 * Origin: A little, after lunch (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