@MSGID: 2@dont-email.me> d882b860
@REPLY: 3@dont-email.me> f94af01c
@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>
5Arqz@news.chiark.greenend.org.uk> 3@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 15:40, candycanearter07 wrote:
> On 9/15/23 08: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.
>>
>> Theo
> 
> I thought double free was a SIGSEGV?

In fact it seems fairly undefined

It looks like it is somewhat implementation dependent. SIGSEGV means you 
accessed unallocated memory, but that is not the same as freeing 
allocated memory, twice.

There seem to be instances of it reported. Google is a friend here.

I *suspect* that if that is the problem, its a signal from deep within libc.
Whereas SIGSEGV probably emanates from a memory management unit somewhere

-- 
"Strange as it seems, no amount of learning can cure stupidity, and 
higher education positively fortifies it."

    - Stephen Vizinczey


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