This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

@dhorak 

This seems to be platform dependent issue, any idea what could be wrong? Is it LTO related?

Actually vips testsuite (i.e. building fedora rawhide vips srpm, then executing $ make check) segfaults, only on ppc64le, like this:

[mockbuild@b92a536d4fff4c6198e4717348f4ee0b vips-8.11.2]$ export LD_LIBRARY_PATH=$(pwd)/./libvips/.libs/
[mockbuild@b92a536d4fff4c6198e4717348f4ee0b vips-8.11.2]$ gdb --args ./tools/.libs/vipsthumbnail ./test/tmp-4907/huge.png -o tmp.png
GNU gdb (GDB) Fedora 10.2-6.fc35
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "ppc64le-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./tools/.libs/vipsthumbnail...
(gdb) r
Starting program: /builddir/build/BUILD/vips-8.11.2/tools/.libs/vipsthumbnail ./test/tmp-4907/huge.png -o tmp.png
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff38feaa0 (LWP 184)]
[New Thread 0x7fffebffeaa0 (LWP 185)]
[New Thread 0x7ffff30eeaa0 (LWP 186)]
[New Thread 0x7ffff28deaa0 (LWP 187)]

Thread 4 "pool-vipsthumbn" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff30eeaa0 (LWP 186)]
0x00007ffff3910344 in ?? ()
(gdb) thread apply all bt

Thread 5 (Thread 0x7ffff28deaa0 (LWP 187) "pool-vipsthumbn"):
#0  0x00007ffff765beac in syscall () at ../sysdeps/unix/sysv/linux/powerpc/syscall.S:30
#1  0x00007ffff7855f04 in g_cond_wait (cond=0x1001b9210, mutex=0x1001b91f0) at ../glib/gthread-posix.c:1574
#2  0x00007ffff7c537ec in vips_semaphore_downn(VipsSemaphore*, int) (s=0x1001b9150, n=<optimized out>) at iofuncs/semaphore.c:124
#3  0x00007ffff7c538cc in vips_semaphore_down(VipsSemaphore*) (s=<optimized out>) at iofuncs/semaphore.c:145
#4  0x00007ffff7c3ca90 in wbuffer_write_thread (data=0x1001b9130, user_data=<optimized out>) at iofuncs/sinkdisc.c:190
#5  0x00007ffff7c54bb4 in vips_thread_main_loop(gpointer, gpointer) (thread_data=0x1001b92f0, pool_data=0x0) at iofuncs/threadpool.c:284
#6  0x00007ffff782bbfc in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:354
#7  0x00007ffff7827560 in g_thread_proxy (data=0x10003c0c0) at ../glib/gthread.c:826
#8  0x00007ffff78588a8 in linux_pthread_proxy (data=0x10003c0c0) at ../glib/gthread-posix.c:1269
#9  0x00007ffff75b6f34 in start_thread (arg=0x7ffff28deaa0) at pthread_create.c:434
#10 0x00007ffff7665a20 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107

Thread 4 (Thread 0x7ffff30eeaa0 (LWP 186) "pool-vipsthumbn"):
#0  0x00007ffff3910344 in  ()
#1  0x00007ffff7051a48 in orc_executor_run (ex=0x7ffff30eab38) at ../orc/orcexecutor.c:51
#2  0x00007ffff30ea4a0 in  ()

Thread 3 (Thread 0x7fffebffeaa0 (LWP 185) "pool-vipsthumbn"):
#0  0x00007ffff765beac in syscall () at ../sysdeps/unix/sysv/linux/powerpc/syscall.S:30
#1  0x00007ffff7855f04 in g_cond_wait (cond=0x1001b8cd0, mutex=0x1001b8cb0) at ../glib/gthread-posix.c:1574
#2  0x00007ffff7c537ec in vips_semaphore_downn(VipsSemaphore*, int) (s=0x1001b8c10, n=<optimized out>) at iofuncs/semaphore.c:124
#3  0x00007ffff7c3caac in wbuffer_write_thread (data=0x1001b8bd0, user_data=<optimized out>) at iofuncs/sinkdisc.c:197
#4  0x00007ffff7c54bb4 in vips_thread_main_loop(gpointer, gpointer) (thread_data=0x1001b8dc0, pool_data=0x0) at iofuncs/threadpool.c:284
#5  0x00007ffff782bbfc in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:354
#6  0x00007ffff7827560 in g_thread_proxy (data=0x10003c000) at ../glib/gthread.c:826
#7  0x00007ffff78588a8 in linux_pthread_proxy (data=0x10003c000) at ../glib/gthread-posix.c:1269
#8  0x00007ffff75b6f34 in start_thread (arg=0x7fffebffeaa0) at pthread_create.c:434
#9  0x00007ffff7665a20 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107

Thread 2 (Thread 0x7ffff38feaa0 (LWP 184) "pool-vipsthumbn"):
#0  0x00007ffff765beac in syscall () at ../sysdeps/unix/sysv/linux/powerpc/syscall.S:30
#1  0x00007ffff7856a14 in g_cond_wait_until (end_time=<optimized out>, mutex=0x100043f80, cond=0x100043f88) at ../glib/gthread-posix.c:1622
#2  g_cond_wait_until (cond=0x100043f88, mutex=0x100043f80, end_time=<optimized out>) at ../glib/gthread-posix.c:1595
#3  0x00007ffff7799c48 in g_async_queue_pop_intern_unlocked (queue=0x100043f80, wait=<optimized out>, end_time=3280045370810) at ../glib/gasyncqueue.c:422
#4  0x00007ffff782be68 in g_thread_pool_wait_for_new_task (pool=<optimized out>) at ../glib/gthreadpool.c:278
#5  g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:343
#6  0x00007ffff7827560 in g_thread_proxy (data=0x10003bf00) at ../glib/gthread.c:826
#7  0x00007ffff78588a8 in linux_pthread_proxy (data=0x10003bf00) at ../glib/gthread-posix.c:1269
#8  0x00007ffff75b6f34 in start_thread (arg=0x7ffff38feaa0) at pthread_create.c:434
#9  0x00007ffff7665a20 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107

Thread 1 (Thread 0x7ffff449ea00 (LWP 181) "vipsthumbnail"):
#0  0x00007ffff765beac in syscall () at ../sysdeps/unix/sysv/linux/powerpc/syscall.S:30
#1  0x00007ffff7855f04 in g_cond_wait (cond=0x1001b9760, mutex=0x1001b9740) at ../glib/gthread-posix.c:1574
#2  0x00007ffff7c537ec in vips_semaphore_downn(VipsSemaphore*, int) (s=0x1001b96d0, n=<optimized out>) at iofuncs/semaphore.c:124
--Type <RET> for more, q to quit, c to continue without paging--
#3  0x00007ffff7c54604 in vips_threadpool_run(VipsImage*, VipsThreadStartFn, VipsThreadpoolAllocateFn, VipsThreadpoolWorkFn, VipsThreadpoolProgressFn, void*) (im=0x1000bc970, start=0x7ffff7c3bf90 <write_thread_state_new>, allocate=0x7ffff7c42960 <wbuffer_allocate_fn>, work=<optimized out>, progress=0x7ffff7c3c3a0 <vips_sink_base_progress>, a=<optimized out>) at iofuncs/threadpool.c:923
#4  0x00007ffff7c42ca4 in vips_sink_disc (im=0x1000bc970, write_fn=0x7ffff7be6390 <write_png_block>, a=0x1001b8380) at iofuncs/sinkdisc.c:512
#5  0x00007ffff7beb6c0 in write_vips (write=write@entry=0x1001b8380, compress=compress@entry=6, interlace=interlace@entry=0, profile=profile@entry=0x0, filter=filter@entry=VIPS_FOREIGN_PNG_FILTER_ALL, strip=strip@entry=0, palette=palette@entry=0, Q=Q@entry=100, dither=dither@entry=1, bitdepth=bitdepth@entry=8) at foreign/vipspng.c:1238
#6  0x00007ffff7beb93c in vips__png_write_target (in=<optimized out>, target=0x1001afa90, compression=<optimized out>, interlace=<optimized out>, profile=0x0, filter=<optimized out>, strip=<optimized out>, palette=<optimized out>, Q=100, dither=1, bitdepth=8) at foreign/vipspng.c:1263
#7  0x00007ffff7bcde90 in vips_foreign_save_png_build(VipsObject*) (object=0x1001b2060) at foreign/pngsave.c:153
#8  0x00007ffff7bc6498 in vips_foreign_save_png_target_build(VipsObject*) (object=0x1001b2060) at foreign/pngsave.c:303
#9  0x00007ffff7c18444 in vips_object_build(VipsObject*) (object=<optimized out>) at iofuncs/object.c:367
#10 0x00007ffff7c395a0 in vips_cache_operation_buildp (operation=0x7fffffff9c90) at iofuncs/cache.c:910
#11 vips_cache_operation_buildp (operation=0x7fffffff9c90) at iofuncs/cache.c:886
#12 0x00007ffff7c40ea8 in vips_call_required_optional (operation=0x7fffffff9c90, required=0x7fffffff9d28 "P\306\v", optional=0x7fffffffbdb0 "") at iofuncs/operation.c:880
#13 0x00007ffff7c41558 in vips_call_by_name (operation_name=<optimized out>, option_string=0x7fffffff9d58 "", required=required@entry=0x7fffffff9d28 "P\306\v", optional=0x7fffffffbdb0 "") at iofuncs/operation.c:920
#14 0x00007ffff7c41a94 in vips_call_split_option_string (operation_name=<optimized out>, option_string=<optimized out>, optional=<optimized out>) at iofuncs/operation.c:1039
#15 0x00007ffff7c2fd8c in vips_image_write_to_file(VipsImage*, char const*, ...) (image=0x1000bc650, name=<optimized out>) at iofuncs/image.c:2687
#16 0x0000000100002cc4 in thumbnail_write_file (process=<optimized out>, filename=0x7ffffffff6e5 "./test/tmp-4907/huge.png", im=0x1000bc650) at vipsthumbnail.c:266
#17 thumbnail_process (name=0x7ffffffff6e5 "./test/tmp-4907/huge.png", process=0x1000ba020) at vipsthumbnail.c:366
#18 0x0000000100002484 in main (argc=<optimized out>, argv=<optimized out>) at vipsthumbnail.c:553


Currently this blocks rubygem-ruby-vips FTBFS

So I tried to forcely disable "ppc64 optimization" as:

%prep
%setup -q
sed -i meson.build -e 's@ppc@xppc@g'

on orc.spec, then actually vips test suite (i.e. "$ make check" after rebuilding vips.srpm) now succeeds,
and rebuilding rubygem-ruby-vips on ppc64le now succeeds without segfault.

So I guess something is wrong with orc ppc64 vectorization code.

(In reply to Mamoru TASAKA from comment #4)
> So I tried to forcely disable "ppc64 optimization" as:
> 
> %prep
> %setup -q
> sed -i meson.build -e 's@ppc@xppc@g'
> 
> on orc.spec, 

Instead of this, doing "$ export VIPS_NOVECTOR=1" workaround this (as suggested on:
https://github.com/libvips/libvips/issues/427 )

https://gitlab.freedesktop.org/gstreamer/orc/-/issues/37

I have forget to link this ^^ upstream report against ORC.

So if I understand it right, then there is an issue the VIPS <-> ORC interface on ppc64le, which still might be uncovering some internal orc issue ...

Is running vips' test-suite reproducing the issue? Is it run during regular Fedora vips builds?

(In reply to Dan Horák from comment #7)
1) It is actually not clear if it is ORC issue or not, but the basic problem is that the ORC test suite is disabled on PPC (and basically everywhere):

~~~~
%check
%ifnarch s390 s390x ppc %{power64} %{arm} i686 aarch64
%meson_test
%endif
~~~

2) Neither vips has enabled test suite:

https://src.fedoraproject.org/rpms/vips/blob/rawhide/f/vips.spec

3) But rubygem-activestorage has enabled test suite which fails once the noarch build is done on ppc

But as per Mamoru's comment, it seems that vips test suite should trigger this issue.

(In reply to Vít Ondruch from comment #8)
> (In reply to Dan Horák from comment #7)
> 1) It is actually not clear if it is ORC issue or not, but the basic problem
> is that the ORC test suite is disabled on PPC (and basically everywhere):
> 
> ~~~~
> %check
> %ifnarch s390 s390x ppc %{power64} %{arm} i686 aarch64
> %meson_test
> %endif
> ~~~

that's why we are tracking upstream orc in our CI, x86_64 + s390x + ppc64le are green there, aarch64 + armv7 (and ppc64) have some issues
 
> 2) Neither vips has enabled test suite:
> 
> https://src.fedoraproject.org/rpms/vips/blob/rawhide/f/vips.spec

OK, we should likely enable it

> 
> 3) But rubygem-activestorage has enabled test suite which fails once the
> noarch build is done on ppc

I see
 
> But as per Mamoru's comment, it seems that vips test suite should trigger
> this issue.

ack, will try myself

(In reply to Dan Horák from comment #9)
> (In reply to Vít Ondruch from comment #8)
> > (In reply to Dan Horák from comment #7)
> > 1) It is actually not clear if it is ORC issue or not, but the basic problem
> > is that the ORC test suite is disabled on PPC (and basically everywhere):
> > 
> > ~~~~
> > %check
> > %ifnarch s390 s390x ppc %{power64} %{arm} i686 aarch64
> > %meson_test
> > %endif
> > ~~~
> 
> that's why we are tracking upstream orc in our CI, x86_64 + s390x + ppc64le
> are green there, aarch64 + armv7 (and ppc64) have some issues

Ah!!! That is hard to figure. Link in the .spec file would probably help.

> ack, will try myself

Thx a lot for help.

I confirm that the vips test suite fails (in test_seq.sh) with plain "make check" and passes when VIPS_NOVECTOR=1 is set. So it was the easy part ...

~~~
$ ./test_seq.sh 
building huge test PNG image ... ok
testing vipsthumbnail ... ./test_seq.sh: line 16:  7923 Segmentation fault      (core dumped) $vipsthumbnail $huge -o $tmp/x.png
vipsthumbnail failed in basic mode
~~~

~~~
$ ../tools/vipsthumbnail tmp-154/huge.png
Segmentation fault (core dumped)

$ LD_LIBRARY_PATH="../libvips/.libs" ../tools/.libs/vipsthumbnail tmp-154/huge.png -o tmp-154/x.png
Segmentation fault (core dumped)
~~~

https://github.com/libvips/libvips/issues/2404

I have filled also VIPS upstream ticket ^^, because so far the issue puzzles me.

Moving to vips, since this seems to be vips issue after all. More details at: https://gitlab.freedesktop.org/gstreamer/orc/-/issues/37#note_1033039

And moving back to orc, since there is orc fix proposed:

https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/58

Sorry for the noise.

I have created PR with the fix:

https://src.fedoraproject.org/rpms/orc/pull-request/2

I'm going to merge and build in ~week if nobody else take care about this issue.

Just FTR, I have also created PR to enable vips test suite to not be the last in the chain:

https://src.fedoraproject.org/rpms/vips/pull-request/2

Thank you for the vips PR. I've merged it!

FEDORA-2021-3160e8272c has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3160e8272c

FEDORA-2021-3160e8272c has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

I have merged and build the PR from comment 17.

@Adam: I have opened PR enabling the test suite everywhere: https://src.fedoraproject.org/rpms/vips/pull-request/3

(In reply to Vít Ondruch from comment #22)
> I have merged and build the PR from comment 17.

Is orc upstream going to merge this? https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/58 seems no movement...

https://src.fedoraproject.org/rpms/vips/pull-request/3 is merged.

(In reply to Mamoru TASAKA from comment #23)
> (In reply to Vít Ondruch from comment #22)
> > I have merged and build the PR from comment 17.
> 
> Is orc upstream going to merge this?
> https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/58 seems no
> movement...

Finally the above MR is merged.