Re: free(): double free detected in tcache 2

> On 26/02/2020 11:18, Graham Cobb wrote:
>> After upgrading to dar 2.6.8 I seem to have hit a (different) bug. 
>> My daily backup now fails with:
> 
>> free(): double free detected in tcache 2
> 
>> So far it has only tried once, and has hit that error. However, I 
>> have never seen it before, and this is the first backup since I 
>> upgraded from dar 2.6.6 yesterday.
> 
> Looking a the difference in dar/libdar between 2.6.6 and 2.6.8 I
> cannot seen any alocation related thing, nor any modification in when
> calling
> external libraries...

Thanks for looking.

> 
> Difficult to know what caused this without more info
> 
> How did you upgrade from 2.6.6 to 2.6.8?
> - was it through distro package upgrade?
> - did you grab the source code and compiled dar yourself?
> 
> both way are valid, the impact are different on libraries dar relies on:
> - in the first case you may have also upgraded some libraries
> - in the second case you have not

Debian package upgrade. And, yes, it did install a new version of
libgcc-s1 (10-20200211-1), which could either have a bug or be exposing
a previously unknown dar bug. There is a newer version of libgcc-s1 in
testing today so I will install that one for tonight's run. There is no
Debian bug report for this, however.

>> I will try to reproduce it, but are there any additional options 
>> you suggest I turn on to get any more information about the problem
>> (assuming it recurs)?
> 
> I would recompile dar activating debugging information
> export CXXFLAGS=-g
> export LDFLAGS=-g
> export CFLAGS=-g
> ./configure --prefix=... etc.
> make
> make uninstall (if you want to remove the old installed dar/libdar
> binaries)
> make install (and not "make install-strip" which would remove all
> symbols including debugging ones)

I'm not going to be able to build dar this evening. For tonight's run I
have enabled core dumps and I might add -va as well to see if there is
any hints from what dar was doing.

> If you have already a core file, I could try to have a look at it with
> gdb, not sure I can get much of it without debugging symbols... but it
> worth trying

I will see if I get anything tonight.

> By the way have you tried the workaround I suggested for the testing
> phase (not using --sequential-read and relying on an isolated catalog)?

No. I don't have isolated catalogs and generating one on-the-fly would
presumably take about as much time as doing the extra slice reads so I
don't plan to bother. But thanks for the suggestion.

Graham