Re: Bug in dar version 2.7.8 (?)

On 05/09/2023 17:51, Andrea Vai wrote:
> Hi,
> Il giorno mar, 05/09/2023 alle 12.27 +0200, Andrea Vai ha scritto:
>> > I am now compiling dar with your patch,and will let you know.
> 
> I have uninstalled dar using dnf, downloaded dar source, 
> patched, compiled it and it seems I get the same error:
> 
> ---- exception type = [BUG] ----------
> 
> [source]
> 
> 	File slice_layout.cpp line 48 : it seems to be a bug here

Pay attention to recreate the isolated catalogue using the recompiled 
dar with the added patch or changed compiler: the generated isolated 
catalogue is corrupted, this is not a problem of reading the isolated 
catalogue but rather of writing it properly.

[...]

> I can wait for the definitive solution or use another workaround, but it may be good to understand why this happens.
> 

Today's experimentation:

First, "funny" thing, the same dar_static binary 
(dar_static_2.7.12.libssh2_x86_64_GNU_Linux available at 
https://dar.edrusb.org/) works fine under Devuan/chimaera (which is 
based on Debian bullseye), while the exact same binary expresses the bug 
under Debian-12 (!) The generated isolated catalogue transferred to the 
other VM stays corrupted or not corrupted depending on the Debian/Devuan 
version it has been generated under. If someone has some idea of what's 
in play here...Linux Kernel??? I'd be glad understanding that!

Anyway, On Debian 12 using gcc-11 (not with gcc-12.2.0) I could 
reproduce and observe the bug in action. This is effectively the lack of 
field initialization that leads gcc to behave strangely with the ternary 
operator (I would have thought that non-zero byte value would be assumed 
to be true). Rolf was right, I was wrong.

Modifying the slice_layout constructor to initializes older_sar_than_v8 
fields to false, avoid the bug to express.

@John, instead of Thomas's patch (which seems to workaround the issue), 
you may prefer to apply the attached patch in Debian distribution, 
waiting for 2.7.13 to be released in a few weeks.

In conclusion and to my point of view, the cause of this issue was a 
lack of initialization in a libdar class, leading gcc-11, gcc-12 and the 
following (as experimented by Thomas) to consider a non-zero byte value 
as neither true nor false in the ternary operator "<bool> : <if-true> ? 
<if-false> ;", when default optimization was set.

> 
> Thank you,
> 
> Andrea
> 
> 
> 

Cheers,
Denis

>

commit d8fb462b4ede6c3535796ad5f82bfcb5db167a44
Author: Denis Corbin <[email protected]>
Date:   Tue Sep 5 22:34:44 2023 +0200

    fixing bug condition with some gcc version
    
    replacing the default constructor by explicit one that performs initialization of slice_layout::older_sar_than_v8

diff --git a/src/libdar/slice_layout.hpp b/src/libdar/slice_layout.hpp
index cea8f778..49bea85d 100644
--- a/src/libdar/slice_layout.hpp
+++ b/src/libdar/slice_layout.hpp
@@ -42,7 +42,7 @@ namespace libdar
     class slice_layout
     {
     public:
-	slice_layout() = default;
+	slice_layout() { older_sar_than_v8 = false; };
 	slice_layout(const slice_layout & ref) = default;
 	slice_layout(slice_layout && ref) noexcept = default;
 	slice_layout & operator = (const slice_layout & ref) = default;