Re: Fwd: Bug#1050663: dar option --on-fly-isolate creates catalogue with broken slice_layout

Hello everyone,

I've been following the discussion here and had a look at the patch and 
the associated code of the class 'slice_layout'.
I noticed one little thing:As far as I can see, the boolean member 
variable 'older_sar_than_v8', which acts as condition in the patched 
code, is not initialized in the constructor.

I'm not familiar with the internals of DAR, so I don't know if 
slice_layout::write can be called without first calling 
slice_layout::read or slice_layout::clear. If it were and I'm right with 
my observation, the variable would be uninitialized in this case and its 
value would be random (or more correctly: determined by the previous 
history).
If it is ensured that 'write' is never called without a previous 'read' 
or 'clear', this can of course be ruled out as the cause.

Best regards

Rolf

Am 03.09.23 um 12:31 schrieb Denis Corbin:
> On 02/09/2023 10:59, Thomas wrote:
>> On Wed, Aug 30, 2023 at 03:24:12PM -0500, John Goerzen wrote:
>>> On Wed, Aug 30 2023, Denis Corbin wrote:
>>>
>>>>> Summary
>>>>> =======
>>>>> g++ 10 works fine with optimization.
>>>>> g++ 11 or newer work only without optimization.
>>>>> Hope this helps.
>>>>
>>>> Thanks for confirming this is a gcc issue. I don't know what should 
>>>> be the next
>>>> step, if someone fills a bug report to gcc Debian maintainer?
>>>
>>> Well, to be sure, we have a couple of possibilities:
>>>
>>> 1) This is a gcc bug,
>>>
>>> or 2) There is something in dar (or, for that matter, bzip2 or some
>>> other library) that is relying on some sort of C/C++ undefined behavior
>>> (UB) that the optimizer is taking in a different direction. Other
>>> possibilities could include race conditions, etc.
>>
>> To find the root cause why the optimizer does something harmfull in our
>> case is way over my head.
>
> ...and mine!
>
>>
>> But...
>> I have found a workaround for dar. The appended patch works for me with
>> dar v2.7.11 and g++ v13.2.0, v12.3.0 and v11.4.0. Means, files generated
>> with OnFlyIsolation are readable again with default optimizations
>> activated.
>> It seems the optimizer does not like the used ternary operator.
>
> interesting finding :) I don't know how you got to find this, but this 
> is valuable! Though, ternary operator is so common in so many 
> software, that I wonder: should we ask all those C and C++ 
> applications to ban this classical C construct from their code, in 
> order to workaround a bug in gcc compiler?
>
> Another point is that if it seems to concerns only gcc (not other 
> compilers like clang), it only concerns some of its versions (version 
> 12 in particular) and it also concern some distributions only:
> gcc-12 under VoidLinux and optimization works well for dar while, as 
> reported by Thomas, it does not seem to work under Debian... Here 
> maybe a component on which gcc relies is problematic, which differs 
> from distro to distro (?)...
>
> Also, the link with libraries dar relies on, does not seems pertinent 
> to me: compiling dar with or without optimization does not change 
> installed/compiled libraries code, they are just linked with dar 
> through the same symbols. In addition to this, the location the "bug" 
> occurs in dar, is pure libdar data structure used in libdar format 
> headers and catalogue, nothing send or used with external libraries.
>
> About race conditions: this usually behaves as non-systematic problem 
> that sometime occurs sometime not, in the same outer conditions. Here 
> the problem systematically shows in some contexts and never in some 
> other contexts. If you do not build dar to rely on libtheadar, 
> dar/libdar only uses one thread: In this condition, if a race takes 
> place, it only has one runner and thus always the same winner...
>
> Last if there was something wrong in dar, shouldn't the compiler 
> complain at compilation time? And IMHO, optimization purpose is not to 
> change the result of a program but to have it using less CPU cycles 
> and/or less memory to do the exact *same* thing as without 
> optimization. So definitively there is something wrong in compiler 
> side, to my point of view.
>
>>
>> I tested the patch with g++ v10.4.0 and 9.3.0, too without problems but
>> these versions are working with or without this patch anyway.
>
> Thank you for the time you take to circumvent the area of the problem. 
> On my side, I'd like to have more free/personal time to work on dar 
> and webdar (project under construction). Thus unless some new element 
> leads to a problem in dar, I can't spend more time on this issue, 
> sorry to say so and I hope you'll understand.
>
> I think the best way to go forward is that you open a bug report at 
> Debian maintainer for gcc, they will qualify and eventually contact 
> the gcc upstream.
>
>>
>> Hope this helps.
>>
>> Tom
>>
>>
>
> Denis
>