Any action on a loaded image is leading to a crash when fotocx is running on a system with too many CPU threads. "Too many" is 40. This started with fotocx 25.2. [dan@talos fotocx.git]$ fotocx :master working directory: /home/dan command: fotocx fotocx-25.4 program exe: /usr/bin/fotocx build date/time: Oct 25 2025 00:00:00 fotocx home folder: /home/dan/.fotocx log file: /home/dan/.fotocx/fotocx-25.4.log ------------------------------------------- start fotocx Mon Nov 17 16:54:56 GTK version: 3.24.49 temp files: /home/dan/.fotocx/temp/temp-91905 load_params() free real memory: 48994 MB image size limits for reasonable performance: view: 7999 megapixels edit: 750 megapixels SMP thread count: 64 locale desktop name: Desktop screen width: 1920 height: 1200 thumbnails folder: /home/dan/.fotocx/thumbnails no image index: reports disabled save_params() start gallery: /home/dan/projects/pc/kp800 start file: /home/dan/projects/pc/kp800/P1040156.JPG startup time: 0.9 secs. m_rotate Fblock Rotate *** stack smashing detected ***: terminated *** zappcrash: ppc64le Fedora release fotocx-25.4 Oct 25 2025 00:00:00 fatal signal: abort *** zappcrash context: (null) | (null) After building a DEBUG build from the 25.40 sources and running it I got [dan@talos fotocx]$ ./fotocx working directory: /home/dan command: ./fotocx fotocx-25.4 program exe: /home/dan/projects/fedora/fotocx/fotocx-25.4-build/fotocx/fotocx build date/time: Nov 17 2025 16:39:20 fotocx home folder: /home/dan/.fotocx log file: /home/dan/.fotocx/fotocx-25.4.log ------------------------------------------- start fotocx Mon Nov 17 16:39:28 GTK version: 3.24.49 temp files: /home/dan/.fotocx/temp/temp-88316 load_params() free real memory: 47318 MB image size limits for reasonable performance: view: 7720 megapixels edit: 724 megapixels SMP thread count: 64 locale desktop name: Desktop screen width: 1920 height: 1200 thumbnails folder: /home/dan/.fotocx/thumbnails no image index: reports disabled save_params() start gallery: /home/dan start file: (null) startup time: 1.0 secs. m_open_file m_edit_hist Fblock Edit Histogram ================================================================= ==88316==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7dfff0a92d60 at pc 0x00001002e400 bp 0x7fffffffcab0 sp 0x7fffffffcad0 WRITE of size 8 at 0x7dfff0a92d60 thread T0 #0 0x00001002e3fc in do_wthreads(void* (*)(void*), int) /home/dan/projects/fedora/fotocx/fotocx-25.4-build/fotocx/fotocx.cc:4075 #1 0x0000103cf028 in PXM_copy(PXM*) /home/dan/projects/fedora/fotocx/fotocx-25.4-build/fotocx/f.pixmap.cc:435 #2 0x00001002a0f0 in edit_setup(editfunc&) /home/dan/projects/fedora/fotocx/fotocx-25.4-build/fotocx/fotocx.cc:3414 #3 0x0000102593d4 in m_edit_hist(_GtkWidget*, char*) /home/dan/projects/fedora/fotocx/fotocx-25.4-build/fotocx/f.refine.cc:81 #4 0x7ffff66ca574 in g_cclosure_marshal_VOID__VOID (/lib64/libgobject-2.0.so.0+0x1a574) (BuildId: cfcb763ae5417c2b0a8a5bc5f78d4deb31731eaf) #5 0x7ffff66c1e30 in g_closure_invoke (/lib64/libgobject-2.0.so.0+0x11e30) (BuildId: cfcb763ae5417c2b0a8a5bc5f78d4deb31731eaf) #6 0x7ffff66ee480 in signal_emit_unlocked_R.isra.0 (/lib64/libgobject-2.0.so.0+0x3e480) (BuildId: cfcb763ae5417c2b0a8a5bc5f78d4deb31731eaf) #7 0x7ffff66f0150 in signal_emit_valist_unlocked (/lib64/libgobject-2.0.so.0+0x40150) (BuildId: cfcb763ae5417c2b0a8a5bc5f78d4deb31731eaf) #8 0x7ffff66f03bc in g_signal_emit_valist (/lib64/libgobject-2.0.so.0+0x403bc) (BuildId: cfcb763ae5417c2b0a8a5bc5f78d4deb31731eaf) #9 0x7ffff66f044c in g_signal_emit (/lib64/libgobject-2.0.so.0+0x4044c) (BuildId: cfcb763ae5417c2b0a8a5bc5f78d4deb31731eaf) #10 0x7ffff709ee7c in gtk_widget_activate (/lib64/libgtk-3.so.0+0x49ee7c) (BuildId: d15f95fde4103e5344854ed079c45c982da8a6fe) #11 0x7ffff6ecf604 in gtk_menu_shell_activate_item (/lib64/libgtk-3.so.0+0x2cf604) (BuildId: d15f95fde4103e5344854ed079c45c982da8a6fe) #12 0x7ffff6ecfc98 in gtk_menu_shell_button_release (/lib64/libgtk-3.so.0+0x2cfc98) (BuildId: d15f95fde4103e5344854ed079c45c982da8a6fe) #13 0x7ffff6eb6284 in gtk_menu_button_release.lto_priv.0 (/lib64/libgtk-3.so.0+0x2b6284) (BuildId: d15f95fde4103e5344854ed079c45c982da8a6fe) #14 0x7ffff6c8a9c4 in _gtk_marshal_BOOLEAN__BOXEDv (/lib64/libgtk-3.so.0+0x8a9c4) (BuildId: d15f95fde4103e5344854ed079c45c982da8a6fe) #15 0x7ffff66bed24 in g_type_class_meta_marshalv (/lib64/libgobject-2.0.so.0+0xed24) (BuildId: cfcb763ae5417c2b0a8a5bc5f78d4deb31731eaf) #16 0x7ffff66f0238 in signal_emit_valist_unlocked (/lib64/libgobject-2.0.so.0+0x40238) (BuildId: cfcb763ae5417c2b0a8a5bc5f78d4deb31731eaf) #17 0x7ffff66f03bc in g_signal_emit_valist (/lib64/libgobject-2.0.so.0+0x403bc) (BuildId: cfcb763ae5417c2b0a8a5bc5f78d4deb31731eaf) #18 0x7ffff66f044c in g_signal_emit (/lib64/libgobject-2.0.so.0+0x4044c) (BuildId: cfcb763ae5417c2b0a8a5bc5f78d4deb31731eaf) #19 0x7ffff70c089c in gtk_widget_event_internal.part.0.lto_priv.0 (/lib64/libgtk-3.so.0+0x4c089c) (BuildId: d15f95fde4103e5344854ed079c45c982da8a6fe) #20 0x7ffff709ecbc in gtk_widget_event (/lib64/libgtk-3.so.0+0x49ecbc) (BuildId: d15f95fde4103e5344854ed079c45c982da8a6fe) #21 0x7ffff6eab194 in propagate_event.lto_priv.0 (/lib64/libgtk-3.so.0+0x2ab194) (BuildId: d15f95fde4103e5344854ed079c45c982da8a6fe) #22 0x7ffff6eac1e4 in gtk_main_do_event (/lib64/libgtk-3.so.0+0x2ac1e4) (BuildId: d15f95fde4103e5344854ed079c45c982da8a6fe) #23 0x7ffff7df34bc in _gdk_event_emit (/lib64/libgdk-3.so.0+0x334bc) (BuildId: d96db302b2a9ce1a211fbd171d2a0c55fb0fcb35) #24 0x7ffff7e7ad0c in gdk_event_source_dispatch.lto_priv.1 (/lib64/libgdk-3.so.0+0xbad0c) (BuildId: d96db302b2a9ce1a211fbd171d2a0c55fb0fcb35) #25 0x7ffff62aa51c in g_main_context_dispatch_unlocked.lto_priv.0 (/lib64/libglib-2.0.so.0+0x7a51c) (BuildId: 60deadef2ea1ec293affc036e5afd1c66820fba1) #26 0x7ffff62b6cc4 in g_main_context_iterate_unlocked.isra.0 (/lib64/libglib-2.0.so.0+0x86cc4) (BuildId: 60deadef2ea1ec293affc036e5afd1c66820fba1) #27 0x7ffff62b7038 in g_main_loop_run (/lib64/libglib-2.0.so.0+0x87038) (BuildId: 60deadef2ea1ec293affc036e5afd1c66820fba1) #28 0x7ffff6ea3890 in gtk_main (/lib64/libgtk-3.so.0+0x2a3890) (BuildId: d15f95fde4103e5344854ed079c45c982da8a6fe) #29 0x000010014f90 in main /home/dan/projects/fedora/fotocx/fotocx-25.4-build/fotocx/fotocx.cc:688 #30 0x7ffff542b220 in __libc_start_call_main (/lib64/libc.so.6+0x2b220) (BuildId: 5201f49164b8a37b30eaeb3be60d96b296e6efc1) #31 0x7ffff542b478 in __libc_start_main_impl (/lib64/libc.so.6+0x2b478) (BuildId: 5201f49164b8a37b30eaeb3be60d96b296e6efc1) Address 0x7dfff0a92d60 is located in stack of thread T0 at offset 352 in frame #0 0x00001002e2c0 in do_wthreads(void* (*)(void*), int) /home/dan/projects/fedora/fotocx/fotocx-25.4-build/fotocx/fotocx.cc:4069 This frame has 1 object(s): [32, 352) 'tid' (line 4070) <== Memory access at offset 352 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /home/dan/projects/fedora/fotocx/fotocx-25.4-build/fotocx/fotocx.cc:4075 in do_wthreads(void* (*)(void*), int) Shadow bytes around the buggy address: 0x7dfff0a92a80: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 0x7dfff0a92b00: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 0x7dfff0a92b80: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 0x7dfff0a92c00: f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 0x7dfff0a92c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x7dfff0a92d00: 00 00 00 00 00 00 00 00 00 00 00 00[f3]f3 f3 f3 0x7dfff0a92d80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x7dfff0a92e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7dfff0a92e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7dfff0a92f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7dfff0a92f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==88316==ABORTING And this leads to the fotocx.cc source file with /********************************************************************************/ // thread: start worker threads (per processor core) and wait for completion // threadfunc: void * func(void *index) // start Nt threads and wait for all to exit void do_wthreads(threadfunc func, int Nt) { pthread_t tid[40]; Funcbusy(+1); for (int ii = 0; ii < Nt; ii++) tid[ii] = start_Jthread(func, &Nval[ii]); for (int ii = 0; ii < Nt; ii++) wait_Jthread(tid[ii]); Funcbusy(-1); return; } and here you can see that if number of thread in the Nt parameter will be greater than 40, it will cause the stack smashing issue. Reproducible: Always Steps to Reproduce: 1. open an image in fotocx 25.2 (or newer) 2. try an action like "Edit / Rotate"
I am going to send an email to the author as I can't see any other way to report an issue in fotocx ...
There are systems with dozens of threads running Fedora (like 80-core/thread aarch64 from Ampere, 176 threads on a dual socket Power9, etc), so capping to eg. 40 threads would make sense. More parallelism would unlikely bring any advantage.
for the record, version 25.5 with a fix should be released soon
FYI, version 25.5 has been released (https://release-monitoring.org/project/371590/), although new bug hasn't been created. No idea how this is managed by packit ...
Not sure why packit isn't packiting, but I'll do it myself.
FEDORA-2025-3bc333785c (fotocx-25.5-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-3bc333785c
FEDORA-2025-9dc63b4a12 (fotocx-25.5-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-9dc63b4a12
FEDORA-2025-3bc333785c has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-3bc333785c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-3bc333785c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-2070e9810d has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-2070e9810d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-2070e9810d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-9dc63b4a12 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-9dc63b4a12` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-9dc63b4a12 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Gwyn Ciesla from comment #5) > Not sure why packit isn't packiting, but I'll do it myself. I think it's because the message about the new release from release-monitoring.org got lost and no "new version" bug has been opened, but I am no expert on packit.
FEDORA-2025-2070e9810d (fotocx-25.5-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-3bc333785c (fotocx-25.5-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-9dc63b4a12 (fotocx-25.5-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.