[32-bit ppc/i386] Advice needed to fix GUI binary, which crashes on launch with `KERN_INVALID_ADDRESS at 0x00000000fffffffc` (CLI binary works) about rawtherapee

[10110111]

Note that the problem may have existed before the commit you found. This commit may have simply uncovered it.

From your stack trace, this line seems to be the one that triggers the crash. You could try adding it on top of a working revision to see if it will start crashing. But the struct itself doesn't seem bad, so it may be that memory is corrupted before this object is constructed.

[barracuda156]

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfffffffc
0x053cfaa8 in std::string::_Rep::_M_is_leaked ()
(gdb) bt
#0  0x053cfaa8 in std::string::_Rep::_M_is_leaked ()
#1  0x0369dc8c in _ZNSsC4ERKSs.isra.0 ()
#2  0x000469c8 in rtengine::procparams::ColorManagementParams::ColorManagementParams ()
#3  0x0001ee44 in __static_initialization_and_destruction_0 ()
#4  0x0001ee94 in _GLOBAL__sub_I_histogrampanel.cc ()
#5  0x8fe15d60 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#6  0x8fe0f70c in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#7  0x8fe0f804 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#8  0x8fe02708 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#9  0x8fe08690 in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_ ()
#10 0x8fe017cc in __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl ()
#11 0x8fe01064 in __dyld__dyld_start ()
(gdb) disassemble $pc-0x10 $pc+0x10
Dump of assembler code from 0x53cfa98 to 0x53cfab8:
0x053cfa98 <_ZNSs4_Rep12_S_empty_repEv+12>:	mtlr    r0
0x053cfa9c <_ZNSs4_Rep12_S_empty_repEv+16>:	addis   r3,r10,4
0x053cfaa0 <_ZNSs4_Rep12_S_empty_repEv+20>:	addi    r3,r3,9180
0x053cfaa4 <_ZNSs4_Rep12_S_empty_repEv+24>:	blr
0x053cfaa8 <_ZNKSs4_Rep12_M_is_leakedEv+0>:	lwz     r3,8(r3)
0x053cfaac <_ZNKSs4_Rep12_M_is_leakedEv+4>:	rlwinm  r3,r3,1,31,31
0x053cfab0 <_ZNKSs4_Rep12_M_is_leakedEv+8>:	blr
0x053cfab4 <_ZNKSs4_Rep12_M_is_sharedEv+0>:	lwz     r0,8(r3)
End of assembler dump.
(gdb)  info registers
r0             0x369dc8c	57269388
r1             0xbfffd4e0	3221214432
r2             0x23a	570
r3             0xfffffff4	4294967284
r4             0x0	0
r5             0x8	8
r6             0x686f746f	1752134767
r7             0xabfc094	180338836
r8             0x2	2
r9             0x140c998	21023128
r10            0x98	152
r11            0x42000408	1107297288
r12            0x53cfaa8	87882408
r13            0x8fe37930	2414049584
r14            0x8fe336bc	2414032572
r15            0x8fe37930	2414049584
r16            0x4f47c	324732
r17            0x8fe34d60	2414038368
r18            0x8fe2b954	2414000468
r19            0x35	53
r20            0x8fe36a24	2414045732
r21            0x2	2
r22            0x147c	5244
r23            0x11e0	4576
r24            0x8fe33ca0	2414034080
r25            0xb9	185
r26            0x124601c	19161116
r27            0x8fe33c48	2414033992
r28            0x125c	4700
r29            0x140c998	21023128
r30            0xfffffff4	4294967284
r31            0x467a0	288672
pc             0x53cfaa8	87882408
ps             0x100000000200f030	1152921504640462896
cr             0x42000402	1107297282
lr             0x369dc8c	57269388
ctr            0x53cfaa8	87882408
xer            0x0	0
mq             0x0	0
fpscr          0x82000000	2181038080
vscr           0x10000	65536
vrsave         0x0	0

[barracuda156]

During the build there are a number of array bounds warnings:

/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.h:165:40: warning: array subscript 0 is outside array bounds of 'void [220]' [-Warray-bounds=]
  165 |             castedSrcImg->resizeImgTo<>(nw, nh, interp, imgPtr);
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc: In static member function 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)':
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:498:31: note: at offset -68 into object of size 220 allocated by 'operator new'
  498 |     Image8* img = new Image8 ();
      |                               ^
In static member function 'static IC* rtengine::Thumbnail::resizeTo(int, int, rtengine::TypeInterpolation, rtengine::ImageIO*) [with IC = rtengine::Image8]',
    inlined from 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:567:42:
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.h:162:40: warning: array subscript 0 is outside array bounds of 'void [220]' [-Warray-bounds=]
  162 |             castedSrcImg->resizeImgTo<>(nw, nh, interp, imgPtr);
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc: In static member function 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)':
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:498:31: note: at offset -68 into object of size 220 allocated by 'operator new'
  498 |     Image8* img = new Image8 ();
      |                               ^
In file included from /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/imageio.h:24,
                 from /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/image8.h:24,
                 from /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:38:
In member function 'void rtengine::PlanarRGBData<T>::resizeImgTo(int, int, rtengine::TypeInterpolation, IC*) const [with IC = rtengine::Image8; T = short unsigned int]',
    inlined from 'static IC* rtengine::Thumbnail::resizeTo(int, int, rtengine::TypeInterpolation, rtengine::ImageIO*) [with IC = rtengine::Image8]' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.h:162:40,
    inlined from 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:567:42:
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/iimage.h:883:13: warning: array subscript 0 is outside array bounds of 'void [220]' [-Warray-bounds=]
  883 |         if (width == nw && height == nh) {
      |             ^~~~~
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc: In static member function 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)':
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:498:31: note: at offset -64 into object of size 220 allocated by 'operator new'
  498 |     Image8* img = new Image8 ();
      |                               ^
In member function 'void rtengine::PlanarRGBData<T>::resizeImgTo(int, int, rtengine::TypeInterpolation, IC*) const [with IC = rtengine::Image8; T = short unsigned int]',
    inlined from 'static IC* rtengine::Thumbnail::resizeTo(int, int, rtengine::TypeInterpolation, rtengine::ImageIO*) [with IC = rtengine::Image8]' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.h:162:40,
    inlined from 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:567:42:
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/iimage.h:885:33: warning: array subscript 0 is outside array bounds of 'void [220]' [-Warray-bounds=]
  885 |             for (int i = 0; i < height; i++) {
      |                                 ^~~~~~
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc: In static member function 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)':
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:498:31: note: at offset -64 into object of size 220 allocated by 'operator new'
  498 |     Image8* img = new Image8 ();
      |                               ^
In member function 'void rtengine::PlanarRGBData<T>::resizeImgTo(int, int, rtengine::TypeInterpolation, IC*) const [with IC = rtengine::Image8; T = short unsigned int]',
    inlined from 'static IC* rtengine::Thumbnail::resizeTo(int, int, rtengine::TypeInterpolation, rtengine::ImageIO*) [with IC = rtengine::Image8]' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.h:162:40,
    inlined from 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:567:42:
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/iimage.h:886:37: warning: array subscript 0 is outside array bounds of 'void [220]' [-Warray-bounds=]
  886 |                 for (int j = 0; j < width; j++) {
      |                                     ^~~~~
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc: In static member function 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)':
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:498:31: note: at offset -64 into object of size 220 allocated by 'operator new'
  498 |     Image8* img = new Image8 ();
      |                               ^
In member function 'void rtengine::PlanarRGBData<T>::resizeImgTo(int, int, rtengine::TypeInterpolation, IC*) const [with IC = rtengine::Image8; T = short unsigned int]',
    inlined from 'static IC* rtengine::Thumbnail::resizeTo(int, int, rtengine::TypeInterpolation, rtengine::ImageIO*) [with IC = rtengine::Image8]' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.h:162:40,
    inlined from 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:567:42:
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/iimage.h:894:30: warning: array subscript 0 is outside array bounds of 'void [220]' [-Warray-bounds=]
  894 |                 int ri = i * height / nh;
      |                              ^~~~~~
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc: In static member function 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)':
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:498:31: note: at offset -64 into object of size 220 allocated by 'operator new'
  498 |     Image8* img = new Image8 ();
      |                               ^
In member function 'void rtengine::PlanarRGBData<T>::resizeImgTo(int, int, rtengine::TypeInterpolation, IC*) const [with IC = rtengine::Image8; T = short unsigned int]',
    inlined from 'static IC* rtengine::Thumbnail::resizeTo(int, int, rtengine::TypeInterpolation, rtengine::ImageIO*) [with IC = rtengine::Image8]' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.h:162:40,
    inlined from 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:567:42:
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/iimage.h:897:34: warning: array subscript 0 is outside array bounds of 'void [220]' [-Warray-bounds=]
  897 |                     int ci = j * width / nw;
      |                                  ^~~~~
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc: In static member function 'static rtengine::Thumbnail* rtengine::Thumbnail::loadQuickFromRaw(const Glib::ustring&, rtengine::eSensorType&, int&, int&, int, bool, bool, bool)':
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_graphics_rawtherapee/rawtherapee/work/rawtherapee-5.10/rtengine/rtthumbnail.cc:498:31: note: at offset -64 into object of size 220 allocated by 'operator new'
  498 |     Image8* img = new Image8 ();
      |                               ^

[10110111]

What if you run the binary under Valgrind?

[barracuda156]

What if you run the binary under Valgrind?

@10110111 Valgrind does not work on Darwin ppc (I think it never did). The only debugger is GDB. Rather dated, but it works.

[10110111]

#0  0x053cfaa8 in std::string::_Rep::_M_is_leaked ()
#1  0x0369dc8c in _ZNSsC4ERKSs.isra.0 ()
#2  0x000469c8 in rtengine::procparams::ColorManagementParams::ColorManagementParams ()

May be useful to build in debug mode and see what's happening at the source level. Maybe the crash will even shift to another place.

[barracuda156]

@10110111 I will try.

By the way do you know if anyone tried building RT against GTK3 X11 (non-quartz) on any macOS? I am a bit concerned here, because source code just injects dedicated chunks without any else parts. Maybe it actually has to have non-Cocoa replacements and not just being removed.

[10110111]

No idea, but given that your crash happens at static initialization, I'd expect there's something in addition to the quartz/X11 distinction. I wonder though, why does RT need such platform-specific code? Where did you find it?

[barracuda156]

@10110111 I wonder as well, it should not be required (though cocoa interface is expected to be smoother, at the cost of poor compatibility).
But nearly always pure GTK+x11 work fine.

I am on mobile now, so no BBEdit, but you could search for __APPLE__ through the sources, it will return those instances. They aren’t numerous, but they are present, and that was the reason the port for RT in Macports was designed to be broken on ppc and i386; I think, completely unnecessarily.

[barracuda156]

@10110111 By the way, I just built it on Sonoma as macOS app (so with gkt3+quartz and without my patches), and it crashes on launch as well, though perhaps for unrelated reason:

Process:               rawtherapee [29058]
Path:                  /Applications/MacPorts/RawTherapee.app/Contents/MacOS/rawtherapee
Identifier:            com.rawtherapee.RawTherapee
Version:               5.10 (5.10)
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               501

Date/Time:             2024-04-23 15:35:19.9171 +0800
OS Version:            macOS 14.4.1 (23E224)
Report Version:        12
Anonymous UUID:        08288255-726E-11E3-9DE3-9407366F4C9A

Sleep/Wake UUID:       4F63D358-BC70-4859-8223-6E1B76A354D5

Time Awake Since Boot: 390000 seconds
Time Since Wake:       2070 seconds

System Integrity Protection: enabled

Crashed Thread:        4

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process:   rawtherapee [29058]

Application Specific Information:
abort() called


Thread 0::  Dispatch queue: com.apple.main-thread
0   liblensfun.0.3.4.dylib        	       0x102a3157c cmp_vignetting(void const*, void const*) + 32
1   liblensfun.0.3.4.dylib        	       0x102a38ed8 _lf_addobj(void***, void const*, unsigned long, bool (*)(void const*, void const*)) + 68
2   liblensfun.0.3.4.dylib        	       0x102a2dfcc _xml_start_element(_GMarkupParseContext*, char const*, char const**, char const**, void*, _GError**) + 3912
3   libglib-2.0.0.dylib           	       0x102cdd090 emit_start_element + 416
4   libglib-2.0.0.dylib           	       0x102cdc244 g_markup_parse_context_parse + 2636
5   liblensfun.0.3.4.dylib        	       0x102a2cfdc lfDatabase::Load(char const*, char const*, unsigned long) + 220
6   liblensfun.0.3.4.dylib        	       0x102a2cd40 lfDatabase::LoadDirectory(char const*) + 216
7   liblensfun.0.3.4.dylib        	       0x102a2cec0 lfDatabase::Load() + 156
8   rawtherapee                   	       0x101764e08 rtengine::LFDatabase::init(Glib::ustring const&) + 212
9   rawtherapee                   	       0x1015677a8 .omp_outlined. + 340
10  libomp.dylib                  	       0x1039656dc __kmp_invoke_microtask + 156
11  ???                           	               0x0 ???
12  ???                           	             0x370 ???
13  ???                           	       0x10397fa98 __kmp_user_lock_kind + 8

Thread 1:
0   libsystem_pthread.dylib       	       0x18fcc5d20 start_wqthread + 0

Thread 2:
0   libsystem_pthread.dylib       	       0x18fcc5d20 start_wqthread + 0

Thread 3:
0   libsystem_kernel.dylib        	       0x18fc8d9ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18fccb55c _pthread_cond_wait + 1228
2   libomp.dylib                  	       0x103949cb4 void __kmp_suspend_64<false, true>(int, kmp_flag_64<false, true>*) + 364
3   libomp.dylib                  	       0x10392b524 kmp_flag_64<false, true>::wait(kmp_info*, int, void*) + 1832
4   libomp.dylib                  	       0x103926aac __kmp_hyper_barrier_release(barrier_type, kmp_info*, int, int, int, void*) + 160
5   libomp.dylib                  	       0x10392a1b8 __kmp_fork_barrier(int, int) + 640
6   libomp.dylib                  	       0x10390435c __kmp_launch_thread + 336
7   libomp.dylib                  	       0x1039487ac __kmp_launch_worker(void*) + 280
8   libsystem_pthread.dylib       	       0x18fccaf94 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18fcc5d34 thread_start + 8

Thread 4 Crashed:
0   libsystem_kernel.dylib        	       0x18fc92a60 __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x18fccac20 pthread_kill + 288
2   libsystem_c.dylib             	       0x18fbd7a20 abort + 180
3   libc++abi.dylib               	       0x18fc81d30 abort_message + 132
4   libc++abi.dylib               	       0x18fc71ec0 demangling_terminate_handler() + 52
5   libc++abi.1.0.dylib           	       0x103f0765c std::__terminate(void (*)()) + 12
6   libc++abi.1.0.dylib           	       0x103f0760c std::terminate() + 60
7   rawtherapee                   	       0x101567a58 .omp_outlined. + 1028
8   libomp.dylib                  	       0x1039656dc __kmp_invoke_microtask + 156
9   ???                           	               0x2 ???
10  ???                           	               0x0 ???
11  ???                           	             0x200 ???
12  ???                           	    0x726854207265 ???

Thread 5:
0   libsystem_kernel.dylib        	       0x18fc8d9ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18fccb55c _pthread_cond_wait + 1228
2   libomp.dylib                  	       0x103949cb4 void __kmp_suspend_64<false, true>(int, kmp_flag_64<false, true>*) + 364
3   libomp.dylib                  	       0x10392b524 kmp_flag_64<false, true>::wait(kmp_info*, int, void*) + 1832
4   libomp.dylib                  	       0x103926aac __kmp_hyper_barrier_release(barrier_type, kmp_info*, int, int, int, void*) + 160
5   libomp.dylib                  	       0x10392a1b8 __kmp_fork_barrier(int, int) + 640
6   libomp.dylib                  	       0x10390435c __kmp_launch_thread + 336
7   libomp.dylib                  	       0x1039487ac __kmp_launch_worker(void*) + 280
8   libsystem_pthread.dylib       	       0x18fccaf94 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18fcc5d34 thread_start + 8

Thread 6:
0   libsystem_kernel.dylib        	       0x18fc8d9ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18fccb55c _pthread_cond_wait + 1228
2   libomp.dylib                  	       0x103949cb4 void __kmp_suspend_64<false, true>(int, kmp_flag_64<false, true>*) + 364
3   libomp.dylib                  	       0x10392b524 kmp_flag_64<false, true>::wait(kmp_info*, int, void*) + 1832
4   libomp.dylib                  	       0x103926aac __kmp_hyper_barrier_release(barrier_type, kmp_info*, int, int, int, void*) + 160
5   libomp.dylib                  	       0x10392a1b8 __kmp_fork_barrier(int, int) + 640
6   libomp.dylib                  	       0x10390435c __kmp_launch_thread + 336
7   libomp.dylib                  	       0x1039487ac __kmp_launch_worker(void*) + 280
8   libsystem_pthread.dylib       	       0x18fccaf94 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18fcc5d34 thread_start + 8

Thread 7:
0   libsystem_kernel.dylib        	       0x18fc8d9ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18fccb55c _pthread_cond_wait + 1228
2   libomp.dylib                  	       0x103949cb4 void __kmp_suspend_64<false, true>(int, kmp_flag_64<false, true>*) + 364
3   libomp.dylib                  	       0x10392b524 kmp_flag_64<false, true>::wait(kmp_info*, int, void*) + 1832
4   libomp.dylib                  	       0x103926aac __kmp_hyper_barrier_release(barrier_type, kmp_info*, int, int, int, void*) + 160
5   libomp.dylib                  	       0x10392a1b8 __kmp_fork_barrier(int, int) + 640
6   libomp.dylib                  	       0x10390435c __kmp_launch_thread + 336
7   libomp.dylib                  	       0x1039487ac __kmp_launch_worker(void*) + 280
8   libsystem_pthread.dylib       	       0x18fccaf94 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18fcc5d34 thread_start + 8

Thread 8:
0   libsystem_kernel.dylib        	       0x18fc8d9ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18fccb55c _pthread_cond_wait + 1228
2   libomp.dylib                  	       0x103949cb4 void __kmp_suspend_64<false, true>(int, kmp_flag_64<false, true>*) + 364
3   libomp.dylib                  	       0x10392b524 kmp_flag_64<false, true>::wait(kmp_info*, int, void*) + 1832
4   libomp.dylib                  	       0x103926aac __kmp_hyper_barrier_release(barrier_type, kmp_info*, int, int, int, void*) + 160
5   libomp.dylib                  	       0x10392a1b8 __kmp_fork_barrier(int, int) + 640
6   libomp.dylib                  	       0x10390435c __kmp_launch_thread + 336
7   libomp.dylib                  	       0x1039487ac __kmp_launch_worker(void*) + 280
8   libsystem_pthread.dylib       	       0x18fccaf94 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18fcc5d34 thread_start + 8

Thread 9:
0   libsystem_kernel.dylib        	       0x18fc8d9ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18fccb55c _pthread_cond_wait + 1228
2   libomp.dylib                  	       0x103949cb4 void __kmp_suspend_64<false, true>(int, kmp_flag_64<false, true>*) + 364
3   libomp.dylib                  	       0x10392b524 kmp_flag_64<false, true>::wait(kmp_info*, int, void*) + 1832
4   libomp.dylib                  	       0x103926aac __kmp_hyper_barrier_release(barrier_type, kmp_info*, int, int, int, void*) + 160
5   libomp.dylib                  	       0x10392a1b8 __kmp_fork_barrier(int, int) + 640
6   libomp.dylib                  	       0x10390435c __kmp_launch_thread + 336
7   libomp.dylib                  	       0x1039487ac __kmp_launch_worker(void*) + 280
8   libsystem_pthread.dylib       	       0x18fccaf94 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18fcc5d34 thread_start + 8


Thread 4 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000000   x1: 0x0000000000000000   x2: 0x0000000000000000   x3: 0x0000000000000000
    x4: 0x000000018fc86268   x5: 0x000000016ffaea00   x6: 0x0000000000000067   x7: 0x0000000000000000
    x8: 0x600cd4d9f2df8126   x9: 0x600cd4d89d257126  x10: 0x0000000000000200  x11: 0x000000016ffae530
   x12: 0x0000600000f4968c  x13: 0x00000000001ff800  x14: 0x00000000000007fb  x15: 0x00000000a6a10002
   x16: 0x0000000000000148  x17: 0x0000000201d42c30  x18: 0x0000000000000000  x19: 0x0000000000000006
   x20: 0x000000016ffaf000  x21: 0x0000000000002103  x22: 0x000000016ffaf0e0  x23: 0x0000000000000002
   x24: 0x0000000073656c69  x25: 0x0000000101a649c0  x26: 0x0000000101a5e038  x27: 0x0000000000000002
   x28: 0x000000010181030c   fp: 0x000000016ffae970   lr: 0x000000018fccac20
    sp: 0x000000016ffae950   pc: 0x000000018fc92a60 cpsr: 0x40001000
   far: 0x0000000000000000  esr: 0x56000080  Address size fault

UPD. Okay, this is because OpenMP support is broken. Disabling it fixes the app.
Okay, now I have a reference: if I can make X11 version work on Sonoma, then that should be reproducible on PowerPC.

[10110111]

And I guess the official release doesn't crash, does it?

[barracuda156]

And I guess the official release doesn't crash, does it?

I build the release version, not the latest master. But anyway, Sonoma crash is caused by OpenMP-related stuff. Without OpenMP it works.

UPD. I will open a separate issue re GTK3+x11, since it crashes on Sonoma without OpenMP enabled either.

UPD2. I got it working on Sonoma with GTK3+x11! Now will try to build the same thing on PowerPC.

[barracuda156]

@10110111 Ok, I am sure now that GTK stuff is unrelated.

While GTK3+x11 may need a bit of work to make it properly usable, it certainly should not segfault on launch if built correctly.

On PowerPC it still does though, with the same error as before.

[barracuda156]

@10110111 Could it be that something implicitly assumes that size of bool is 1 byte and either struct size, or alignments, or sfinae are conditional on that? If so, that gonna explain the breakage on ppc, since bool is 4 bytes.

[10110111]

Debugging broken assumptions about type sizes can be really hard. But it still may be useful to build with debug symbols and look where exactly and how the crash occurs. If it's still inside static initialization, then look at which variables are being initialized, what they contain etc.

[Floessie]

If so, that gonna explain the breakage on ppc, since bool is 4 bytes.

I used to build RT on Debian PPC where it ran just fine. In this environment sizeof(bool) is 1, though.

[barracuda156]

If so, that gonna explain the breakage on ppc, since bool is 4 bytes.

I used to build RT on Debian PPC where it ran just fine. In this environment sizeof(bool) is 1, though.

@Floessie Given that conversion with rawtherapee-cli works fine, and GTK-x11 issues seem to be ruled out, I suspect it is something silly like size of bool or spinlock. The problem is that @10110111 is right, these things are hard to track down.

[barracuda156]

@Floessie @10110111 Somewhat good news, in a sense: I have built it now on 10.6 i386 and got the same segfault on launch with the same message.

So this has nothing to do with PowerPC, endianness or size of bool (which is standard on i386).
It is very likely it is just broken on 32-bit now. If not, then some settings for GCC builds are wrong.

[barracuda156]

This on i386:

(gdb) where
#0  0x91ed9436 in std::string::_Rep::_M_is_leaked ()
#1  0x01a17857 in _ZNSsC4ERKSs.isra.0 ()
#2  0x008cf855 in rtengine::procparams::ColorManagementParams::ColorManagementParams ()
#3  0x00b1f7cb in _GLOBAL__sub_I_histogrampanel.cc ()
#4  0x8fe0ec6d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#5  0x8fe0ed59 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#6  0x8fe052e2 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#7  0x8fe083e9 in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_ ()
#8  0x8fe01960 in __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl ()
#9  0x8fe01057 in __dyld__dyld_start ()
(gdb) disassemble $pc-0x10 $pc+0x10
Dump of assembler code from 0x91ed9426 to 0x91ed9446:
0x91ed9426 <_ZNSs4_Rep12_S_empty_repEv+7>:	add    %bl,-0x73(%ecx)
0x91ed9429 <_ZNSs4_Rep12_S_empty_repEv+10>:	subl   $0xe58955c3,-0x36f1c064(%ecx)
0x91ed9433 <_ZNKSs4_Rep12_M_is_leakedEv+3>:	mov    0x8(%ebp),%eax
0x91ed9436 <_ZNKSs4_Rep12_M_is_leakedEv+6>:	mov    0x8(%eax),%eax
0x91ed9439 <_ZNKSs4_Rep12_M_is_leakedEv+9>:	shr    $0x1f,%eax
0x91ed943c <_ZNKSs4_Rep12_M_is_leakedEv+12>:	leave  
0x91ed943d <_ZNKSs4_Rep12_M_is_leakedEv+13>:	ret    
0x91ed943e <_ZNKSs4_Rep12_M_is_sharedEv+0>:	push   %ebp
0x91ed943f <_ZNKSs4_Rep12_M_is_sharedEv+1>:	mov    %esp,%ebp
0x91ed9441 <_ZNKSs4_Rep12_M_is_sharedEv+3>:	mov    0x8(%ebp),%eax
0x91ed9444 <_ZNKSs4_Rep12_M_is_sharedEv+6>:	mov    0x8(%eax),%eax
End of assembler dump.
(gdb) info registers
eax            0xfffffff4	-12
ecx            0x0	0
edx            0x0	0
ebx            0xf8c64c	16303692
esp            0xbfffd698	0xbfffd698
ebp            0xbfffd698	0xbfffd698
esi            0xfffffff4	-12
edi            0xf8c5ac	16303532
eip            0x91ed9436	0x91ed9436 <std::string::_Rep::_M_is_leaked() const+6>
eflags         0x10282	66178
cs             0x17	23
ss             0x1f	31
ds             0x1f	31
es             0x1f	31
fs             0x0	0
gs             0x37	55

[10110111]

It is very likely it is just broken on 32-bit now.

I wouldn't be surprised, given the issue where you pinged me.

On my machine with 32-bit userspace I have RT 5.5 built (with the patch ed5cf13 and a few compatibility hacks for GTK<3.16), which works well enough. So one way to debug this for you is to try building 5.5 and see if it works, and then use git bisect to find the commit where things break.

Or you can actually use Valgrind now. Just note that it doesn't support SSE4, AVX or newer extensions on 32-bit x86, so you may need to make sure your binary and all the libraries it loads don't use them (or just execute this on an SSE4&AVX-disabled CPU/kernel/VM). And don't forget to build in debug mode, it'll make your life easier.

[barracuda156]

@10110111 I suspect this commit might have broken it: 8accebe
So I will start from reverting this one. Bisecting back to 5.5 will be a pretty non-trivial endeavor :)

[barracuda156]

@10110111 @Floessie Bingo, it is exactly that commit.

I got now another error on launch, but this looks trivial:

36-242% rawtherapee
ERROR: Can't create "/Users/svacchanda/Library/Application Support/RawTherapee/cache/svg2png/72" cache folder: Unknown error: -1
ERROR: Can't create "/Users/svacchanda/Library/Application Support/RawTherapee/cache/svg2png/72" cache folder: Unknown error: -1
ERROR: Can't create "/Users/svacchanda/Library/Application Support/RawTherapee/cache/svg2png/72" cache folder: Unknown error: -1

P. S. @Lawrence37 Could you please take a look at the issue? 8accebe commit led to segfaults on 32-bit platforms.

[barracuda156]

Did not notice, this is the end of the new error message:

ERROR: Can't create "/Users/svacchanda/Library/Application Support/RawTherapee/cache/svg2png/72" cache folder: Unknown error: -1

(rawtherapee-orig:70848): Gdk-ERROR **: 13:51:28.832: The program 'rawtherapee-orig' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 241 error_code 8 request_code 140 (RENDER) minor_code 27)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
zsh: trace trap  rawtherapee

[barracuda156]

Maybe it was not the best idea to build from a commit (I used 6a11c59 which directly preceded the breakage); let me try 5.10-rc1 instead.

[Floessie]

@barracuda156 Sorry, but I'm unable to reproduce the crash on Debian Testing i386 with current dev and GCC 13.2.0 as well as Clang 16.0.6. And as @10110111 already mentioned, the code looks valid. Tooling/toolchain issue?

[barracuda156]

@barracuda156 Sorry, but I'm unable to reproduce the crash on Debian Testing i386 with current dev and GCC 13.2.0 as well as Clang 16.0.6. And as @10110111 already mentioned, the code looks valid. Tooling/toolchain issue?

@Floessie Thank you, this is helpful to know.

At the moment I do not know the cause, I am building now 5.9, and I am yet to build from current dev (I have been using 5.10 release initially).
Generally speaking, gcc should be fine (especially given that I got the same error on i386, so ppc-specific stuff should be irrelevant), and gtk3 works fine with numerous other ports. However, there are too many “moving parts”, the only conclusive way will be to eventually bisect and get the first breaking commit.

[barracuda156]

@10110111 @Floessie A quick update. I got 5.9 GUI starting up on PowerPC.
However, it is unresponsive. Nothing is clickable, though it does not crash.

UPD. No, it actually works. It is just slow LOL
UPD2. It is even usable. Starting up is slow, once that done, it is okay.

[barracuda156]

[barracuda156]

@barracuda156 Sorry, but I'm unable to reproduce the crash on Debian Testing i386 with current dev and GCC 13.2.0 as well as Clang 16.0.6. And as @10110111 already mentioned, the code looks valid. Tooling/toolchain issue?

Unfortunately, building from dev is problematic now, since the following two commits have effectively pulled in Rust dependency. And Rust is broken.
89d2bdc
36222d1

I have opened an issue for that: #7060

(I could revert them as a one-time fix in the worst case, but it won’t be practical to keep carrying those, it is 2000 LoC. I may not even be allowed to add such a monstrous patch, since I am not a port’s maintainer.)

[barracuda156]

@10110111 @Floessie

I can confirm that reverting 8accebe from 5.10 release fixes the segfault on launch with GUI.

I still get a very odd effect of the interface being initially unresponsive: when I built 5.9, I thought it is just dead, but then suddenly it started working without any action from my side (I think I restarted the app, but that’s it).
I have 5.10 now, and interface again unresponsive. I will perhaps return to this tomorrow to investigate, however as a matter of fact segfault issue is clearly fixed by reverting that single commit.

[10110111]

If you can reproduce the crash on some clean x86 Linux installation (e.g. in a VM), please post the instructions. I might have a look.

[barracuda156]

@10110111 Could you suggest what might lead to GUI being non-reacting to anything? There is no freeze of the app, no errors, GUI is just not responding to clicks on anything. The only thing which works is pop-up commentaries when I place a cursor over something.

I think I have used identical build for 5.10 (where GUI is unresponsive) and 5.9 (where everything works), save for the patch to fix segfault on 5.10.

[10110111]

The only thing which works is pop-up commentaries when I place a cursor over something.

Do you mean the black rounded-rectangular tooltip windows like e.g. "Show only images not in trash."? And what about the buttons themselves — do they change their look to prelit when hovered over?

Such behavior doesn't sound familiar. But, since you have a working version and a non-working one, binary search is again the easiest way to go.

[barracuda156]

The only thing which works is pop-up commentaries when I place a cursor over something.

Do you mean the black rounded-rectangular tooltip windows like e.g. "Show only images not in trash."? And what about the buttons themselves — do they change their look to prelit when hovered over?

Yes to the tooltips, no to button being prelit. Scrolling does not work either.

Such behavior doesn't sound familiar. But, since you have a working version and a non-working one, binary search is again the easiest way to go.

I browsed through commit history, and one thing which looks suspicious is a massive change related to mutices. Looks like that landed in 5.10-pre.
Binary search – you mean via hex editor?

[10110111]

Binary search – you mean via hex editor?

No, git bisect.

[barracuda156]

Binary search – you mean via hex editor?

No, git bisect.

Ah okay, got it. May take a bit of time, but yes, I will proceed with that. I want this working, certainly.

[barracuda156]

@10110111 Looks like it was a ridiculously silly issue (not the segfault, that one is real, but the unresponsiveness): the app opens a welcome window behind the main one and expects one to click there to confirm. Since it is behind, I simply did not see it LOL

So everything works in 5.10, it seems, after reverting 8accebe
There is no problem with mutices etc.

[10110111]

the app opens a welcome window behind the main one and expects one to click there to confirm.

This is crazy. Given the symptoms, the dialog is modal (just checked with GEdit's About dialog), which implies it must be on top of its parent. If your WM doesn't show it on top of its parent, then I'd call it a bug in the WM.

[barracuda156]

the app opens a welcome window behind the main one and expects one to click there to confirm.

This is crazy. Given the symptoms, the dialog is modal (just checked with GEdit's About dialog), which implies it must be on top of its parent. If your WM doesn't show it on top of its parent, then I'd call it a bug in the WM.

Possibly, I make no claim that this is a bug in RT.
Rebuilding now to ensure it works reproducibly.

If yes, then the only issue is that segfault. I will see if it happens with a standard Macports setup for 10.6.8 i386 (which uses clang); if it does, then it is reproducible. If not, it could be an issue with gcc or something else. My PowerPC setup is anything but standard :)

P. S. For the silly window issue, I think we can add a note to the port, which will be displayed only for archaic macOS versions, informing a user about this caveat.

[barracuda156]

@10110111 Looks good, yeah: