Dear Maintainer,

flam3-genome randomly segfaults on ppc64el, but runs OK on all other
architectures.

See
https://ci.debian.net/packages/f/flam3/testing/ppc64el/
segfaults maybe one run in five.

See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001667

Hello,
tried to reproduce the issue and got on a first run this stack:

(gdb) bt
#0  iter_thread_int (fth=0x157681210) at rect.c:500
#1  0x00007fffaa36bad0 in iter_thread_float () at rect.c:253
#2  0x00007fffa9c9b010 in start_thread (arg=0x7fffa740f100) at pthread_create.c:444
#3  0x00007fffa9d3e364 in .LY__clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107
(gdb)

More details in attached file.

Kind regards,
Bernhard

On 13/04/2024 10:45, Bernhard Übelacker wrote:

Hi Bernard,

Many thanks for looking at this, but I'm afraid I still can't see any
obvious solution.

The failing instruction is

   500                 if (p[3]==1.0) {

I assume the issue is with p[3] rather than 1.0,
but the gbd dump shows p[3] holding a valid value!

   (gdb) print p[3]
   $8 = 1


If anyone with access to hardware was minded to have a further look,
it might be interesting to see if the program works without optimisation,
or maybe with just -O1   (set in Makefile.am)


Kind Regards,
Peter

On Fri, 19 Apr 2024 10:34:30 +0100 Peter Blackman <peter@pblackman.plus.com> wrote:

Hello Peter,

Thanks for the suggestion. I have access to the ppc64el hardware, and I
will look into this.


Best Regards,
Trupti

As you suggested, I tried setting the optimization level to -O1 in
Makefile.am, and the program ran without any segmentation faults.

Below are the result :



autopkgtest [14:06:20]: test genome.sh: preparing testbed
Reading package lists...
Building dependency tree...
Reading state information...
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
autopkgtest [14:06:21]: test genome.sh: [-----------------------
+ set -e
+ env seed=22839 issac_seed=12917 flam3-genome
+ xmllint -noout random.flam3
+ env ss=12 qs=6 flam3-render
chaos: 100.0%  took: 1 seconds
filtering...writing 00000.png...done.
+ pngcheck 00000.png
zlib warning:  different version (expected 1.2.13, using 1.3.1)

OK: 00000.png (1200x1200, 32-bit RGB+alpha, non-interlaced, 69.5%).
autopkgtest [14:06:24]: test genome.sh: -----------------------]
autopkgtest [14:06:24]: test genome.sh:  - - - - - - - - - - results - -
- - - - - - - -
genome.sh            PASS
autopkgtest [14:06:24]: @@@@@@@@@@@@@@@@@@@@ summary
convert.sh           PASS
animate.sh           PASS
render.sh            PASS
genome.sh            PASS


Best Regards,
Trupti

Hi Trupti,

Thanks for looking at this.
Does it run consistently at -O1?
(At -O3, sometimes it works, sometimes it doesn't)


I should have mentioned earlier,
I have a little test script, that I attached to #1001667

A run of a minute or two would suffice to show any issues.


Would be interesting to know what happens with -O2,
as I like to use the highest optimisation that is stable.

Wondering whether this really is a bug in gcc...


Best regards,
Peter

Hello Peter,

  You are right, I tested using your script, and the program crashes
randomly.

I tried multiple approaches and found that reducing the optimization
level from -O3 to -O2,-O1 does not resolve the segmentation faults.

However, when I removed only the -ffast-math flag (while keeping other
optimizations) from Makefile.am, the program ran consistently without
any segmentation faults.

This seems to indicate that the instability is likely related to the
-ffast-math flag, rather than the optimization level itself.


Thanks Trupti

Interesting!  I was not expecting -ffast-math to be the cause of the trouble.

Attaching a rules file to use clang. (Clang seems to break dwz!)

If you are happy to try this, it would show if the problem is with gcc.
If the build works with clang with -ffast-math enabled,
I will raise a bug against gcc for this.

Cheers,
Peter

Thanks for suggestion.
Yes, I tested the build using Clang with -ffast-math enabled, but
unfortunately the genome.sh test still results in a segmentation fault
when run in a loop.

I will once again debug the issue using the gdb tool to get more
clarity.Any additional insights or suggestions are most welcome.

Best Regards,
Trupti

Hi Trupti,

Just to be sure this is not an own goal,
I attach a series file that comments out
all the non essential patches.


 From the gcc man page, -ffast-math enables the following optimisations

Hi Peter,

As per the list of flags you provided, I tested each one to identify
which flag triggers the segmentation fault.

I found that the -ffinite-math-only flag is the cause of the
segmentation fault.

Thanks and Regards,
Trupti

Hi Trupti,

I assume then, that adding -fno-finite-math-only to

export DEB_CFLAGS_MAINT_APPEND =

in debian/rules should fix the problem?


I tried this locally on amd64, and cannot detect
any performance hit, so I am tempted to make this
a general change, not just specific to ppc64el

Thanks for your assistance with this bug.

Regards,
Peter

Hi Peter,

Yes, that's correct. I verified this by adding -fno-finite-math-only to
debian/rules on the ppc64el machine, and it resolved the segmentation
faults.

So, we can make this change.

Thanks
Trupti.

Thanks for confirming.
I'll include the fix in the next upload.

Regards,
Peter