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

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