@MSGID: 2@dont-email.me> b1a18122
@REPLY: 3@dont-email.me> df41c5a1
@REPLYADDR vallor <vallor@cultnix.org>
@REPLYTO 2:5075/128 vallor
@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> 5Arqz@news.chiark.greenend.org.uk>1@dont-email.me>
1@dont-email.me>3@dont-email.me>
@TZUTC: -0000
@TID: FIDOGATE-5.12-ge4e8b94
On Fri, 15 Sep 2023 16:46:43 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote in 3@dont-email.me>:

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

Yes -- and the old file remains allocated on disk until
its file descriptor is closed.

-- 
-v
--- FIDOGATE 5.12-ge4e8b94
 * 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