@MSGID: 3@dont-email.me> df41c5a1
@REPLY: 1@dont-email.me> 54bdcf0a
@REPLYADDR The Natural Philosopher
<tnp@invalid.invalid>
@REPLYTO 2:5075/128 The Natural Philosopher
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 3@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>
5Arqz@news.chiark.greenend.org.uk> 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:12, vallor wrote:
> On Fri, 15 Sep 2023 14:56:23 +0100, The Natural Philosopher
> <tnp@invalid.invalid> wrote in 1@dont-email.me>:
> 
>> On 15/09/2023 14:23, Theo wrote:
>>> In comp.sys.raspberry-pi The Natural Philosopher <tnp@invalid.invalid>
>>> wrote:
>>>> On 15/09/2023 12:12, Ralf Fassel wrote:
>>>>> |                             {
>>>>> |                             *q++=0;
>>>>> |                             thermometers[i].name=strdup(p); //
>>>>> |                             make a copy of the name and attach it |
>>>>>                              to our thermometer structure
>>>>>
>>>>> Memory leak if thermometers[i].name already contains something.
>>>>>
>>>> further up the line...
>>>>
>>>>           bzero(filbuf,sizeof(filbuf));
>>>>           /** first thing to do is clean any allocated memory used to
>>>>           store
>>>> values. **/
>>>>           for(i=0;i >>>>                   free(thermometers[i].name);
>>>
>>> You could get a SIGABRT if you were trying to free something that was
>>> already freed.  Are you sure those are interlocked such that for each i
>>> you call strdup() exactly once, and subsequently free() exactly once?
>>> If there was some code path that was breaking out of the loop or
>>> similar you might get such behaviour.
>>>
>> Hmm. I free the pointers even for relay zones that don`t have
>> thermometers, whose pointers are 0. That isn`t an issue.
>>
>> But that might be a remotely possible  issue. I dont zero the pointers
>> after freeing them as far as I can tell. The silly thing is that this
>> program doesn`t use the name anyway.
>>
>> Its used elsewhere Well I don`t think its an issue, but I can zero the
>> pointers anyway after free()ing
>>
>>> Theo
> 
> Hi, read the thread with interest.
> 
> If you`re getting SIGABRT, that`s almost always the software
> calling abort(3).  If you aren`t, maybe there`s a library calling it?
> 
> $ man 7 signal
> [...]
>         Signal      Standard   Action   Comment
>         SIGABRT      P1990      Core    Abort signal from abort(3)
> [but it also lists]
>         SIGIOT         -        Core    IOT trap. A synonym for SIGABRT
>   _ _ _ _ _ _ _
> 
> Meanwhile, if you want to avoid locking your file, you might want to write
> a fresh file with a unique name, then rename() it,
> which -- please correct me if I`m wrong -- should replace
> the desired file atomically.
> 

I think the consensus is that it does.

Presumably if the read process has the old file open, that will be valid 
until it closes it?


-- 
"I guess a rattlesnake ain`t risponsible fer bein` a rattlesnake, but ah 
puts mah heel on um jess the same if`n I catches him around mah chillun".


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