SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Launch the app OBSERVED RESULT A red (attached) flag with the title in it: R engine has died, The backend process failed to start with exit code 6. EXPECTED RESULT Launching the app correctly SOFTWARE/OS VERSIONS macOS: Monterrey 12.2 ADDITIONAL INFORMATION Im currently trying to run the lastest R and RKward version, 4.1.2 and 0.7.2 respectively. The software can't start the R backend (i dont know what that is) and it freezes completely, i have to force the exit every time. I tried to download an older version of RKward (0.7.0) with the same R version I currently run and that version of RKward gives the exactly same error but i cant close the window and work on some very basic things like creating a dataset, everything else is locked (in gray). The R installation is working fine, I use RCommander and RStudio without inconveniences but wanted to migrate to RKward. Thanks
For the sake of narrowing down the issue, could you try installing R 4.0.1, and try with that? If installing in parallel to R 4.1.2, start RKWard from the command line as: /Applications/KDE/rkward.app/Contents/MacOS/rkward --r-executable=/Library/Frameworks/R.framework/Versions/4.0/Resources/bin/R (Please take the paths involved with a grain of salt, I don't have easy access to a mac). Also, please try running as: /Applications/KDE/rkward.app/Contents/MacOS/rkward --debug-level 5 then locate the debug files inside $TMPDIR (one for the frontend, one for the backend), and attach them, here. Thanks!
Ok, I did some testing. I can replicate the problem with R 4.1. Problem is that one of the linked libraries tries to use a path from R 4.0 (which is what the RKWard binary was compiled against). Installing R 4.0, instead of 4.1, allows RKWard to start. I am aware this is not exactly a fix, and worse, it seems RKWard will not start when both R 4.0 and R 4.1 are installed in parallel, either. A solution to this should be as "easy" as building a new version compiled against R 4.1. Unfortunately, our build process on Mac is currently broken due to an unrelated issue ( https://mail.kde.org/pipermail/kde-windows/2022-February/011609.html ), so this may take a while.
(In reply to Thomas Friedrichsmeier from comment #2) > Ok, I did some testing. I can replicate the problem with R 4.1. Problem is > that one of the linked libraries tries to use a path from R 4.0 (which is > what the RKWard binary was compiled against). > > Installing R 4.0, instead of 4.1, allows RKWard to start. I am aware this is > not exactly a fix, and worse, it seems RKWard will not start when both R 4.0 > and R 4.1 are installed in parallel, either. > > A solution to this should be as "easy" as building a new version compiled > against R 4.1. Unfortunately, our build process on Mac is currently broken > due to an unrelated issue ( > https://mail.kde.org/pipermail/kde-windows/2022-February/011609.html ), so > this may take a while. Thank you for your comments on this Thomas, I'll try in the afternoon with the older version of R and will be back.
Meanwhile I managed to get our MacOS builds back online, but I now believe the problem is not actually related to the version of R, but to changes in the codesigning. If you have a few minutes to spare, could you download and test this new build: https://binary-factory.kde.org/view/MacOS/job/RKWard_Nightly_macos/lastSuccessfulBuild/artifact/rkward-master-992-macos-64-clang.dmg ? It will _not_ fix the problem, but it should give some additional info on the cause of the problem. Could you copy and post that?
Update: The current build now starts again, with both R 4.0.2 and R 4.1.2(*), but my testing is limited to Mojave. Since issues related to codesigning / gatekeeper vary a lot between MacOS versions, testing would be much appreciated. (*) Actually, on R 4.1.2 on-screen plots will not work, however, this time the problem is a simple version mismatch and ought to be fixed with tomorrows build. (For signed binaries, I need to rely on the automated daily builds, which puts an obvious limit on how fast I can fix even simple problems...) Link to today's semi-functional DMG: https://binary-factory.kde.org/view/MacOS/job/RKWard_Nightly_macos/lastSuccessfulBuild/artifact/rkward-master-993-macos-64-clang.dmg Link to latest build at all times: https://binary-factory.kde.org/view/MacOS/job/RKWard_Nightly_macos/
I believe this to be fixed in RKWard 0.7.3 (and 0.7.4). If it is not, please write back.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!