@MSGID: 1@dont-email.me> 54bdcf0a
@REPLY: 1@dont-email.me> c56a6da7
@REPLYADDR vallor <vallor@cultnix.org>
@REPLYTO 2:5075/128 vallor
@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>
5Arqz@news.chiark.greenend.org.uk>1@dont-email.me>
@TZUTC: -0000
@TID: FIDOGATE-5.12-ge4e8b94
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.

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