@MSGID: 1@dont-email.me> 1da19db0
@REPLY: <wwvmsxncw2o.fsf@LkoBDZeT.terraraq.uk>
d51500e4
@REPLYADDR The Natural Philosopher
<tnp@invalid.invalid>
@REPLYTO 2:5075/128 The Natural Philosopher
@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> 3@dont-email.me>
<wwvmsxncw2o.fsf@LkoBDZeT.terraraq.uk>
@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:09, Richard Kettlewell wrote:
> candycanearter07 <no@thanks.net> writes:
>> On 9/15/23 08:23, Theo wrote:
>>> 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.
>>
>> I thought double free was a SIGSEGV?
> 
> If Glibc detects it you`ll get a diagnostic and SIGABRT.

I think that is conclusive.

It seems to have been a double free caused by lack of defensive coding 
plus an asynch timed file write function causing the temporary creation 
of an empty file, or perhaps no file at all.



> 
> If it doesn`t detect it then anything could happen - SIGSEGV is just one
> possibility.
> 

-- 
I would rather have questions that cannot be answered...
...than to have answers that cannot be questioned

Richard Feynman



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