[32-bit ppc/i386] Advice needed to fix GUI binary, which crashes on launch with KERN_INVALID_ADDRESS at 0x00000000fffffffc (CLI binary works)
#7052
Comments
|
|
During the build there are a number of array bounds warnings: |
|
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. |
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. |
|
@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 |
|
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? |
|
@10110111 I wonder as well, it should not be required (though cocoa interface is expected to be smoother, at the cost of poor compatibility). I am on mobile now, so no BBEdit, but you could search for |
|
@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: UPD. Okay, this is because OpenMP support is broken. Disabling it fixes the app. |
|
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. |
|
@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. |
|
@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 |
|
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. |
I used to build RT on Debian PPC where it ran just fine. In this environment |
@Floessie Given that conversion with |
|
@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). |
barracuda156
changed the title
KERN_INVALID_ADDRESS at 0x00000000fffffffc (CLI binary works)KERN_INVALID_ADDRESS at 0x00000000fffffffc (CLI binary works)
|
This on i386: |
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 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. |
|
@10110111 @Floessie Bingo, it is exactly that commit. I got now another error on launch, but this looks trivial: P. S. @Lawrence37 Could you please take a look at the issue? 8accebe commit led to segfaults on 32-bit platforms. |
|
Did not notice, this is the end of the new error message: |
|
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. |
|
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 Sorry, but I'm unable to reproduce the crash on Debian Testing i386 with current |
@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). |
|
|
Unfortunately, building from dev is problematic now, since the following two commits have effectively pulled in Rust dependency. And Rust is broken. 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.) |
|
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). |
|
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. |
|
@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. |
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. |
Yes to the tooltips, no to button being prelit. Scrolling does not work either.
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. |
No, |
Ah okay, got it. May take a bit of time, but yes, I will proceed with that. I want this working, certainly. |
|
@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 |
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. 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. |
|
@10110111 Looks good, yeah:
|
Could someone help me a bit? I got 5.10 built on macOS PowerPC and CLI converter seems working (I was able to throw a PEF at it and get a jpeg), but GUI crashes on launch:
It is likely this is NOT a bug in RawTherapee, but rather a consequence of using an unsupported presently Unix-like build on macOS. That is, I had to patch out Cocoa-specific chunks in a couple of source files (which uses
gtkosxapplication).It would be great though if this issue is not just closed as wontfix, since while Cocoa stuff is pretty broken on older macOS, GTK3 as such and X11 work fine and are well-tested in real applications. Also RawTherapee as such also works (conversion functionality at least).
So it could be a matter of a few minor tweaks, and we get the app working. People will be happy to have a modern RAW converter on PowerPC :)
Any suggestions are greatly appreciated. I realize that the hardware may not be available for testing, but making an educated guess can be nevertheless helpful. I can try any potential fixes on my end and provide logs and GDB output.
The text was updated successfully, but these errors were encountered: