Hello, I may add a final message in case someone looks up this issue online regarding RStudio:
Everything seems to be resolved in combination with RStudio version 2024.10.0-daily+223, while it would still crash with RStudio 2024.09.0+375 (the current stable release). I’ve not tried to track down what caused it to work again, but the change must be very recent. The bottom line is, however, that R-devel now works again with the R GUI and the RStudio in the newest developer builds that are available currently. Thanks once more for all super fast support and kind regards, Sebastian > On 26. Sep 2024, at 05:15, Simon Urbanek <simon.urba...@r-project.org> wrote: > > Sebastian, > > The R GUI problem has been identified (R-devel removed R_SetOptionWidth() > which broke the GUI) and is now fixed (Mac-GUI r8453). > > I cannot comment on RStudio issues, but you mentioned packages: check your > .libPaths() and make sure you remove (or re-install) *all* packages since > packages are not compatible between R versions. > > Cheers, > Simon > > >> On 26 Sep 2024, at 11:42, Simon Urbanek <simon.urba...@r-project.org> wrote: >> >> Sebastian, >> >> thanks, I can replicate the crash in the R GUI and it’s due to a missing >> symbol detected at run-time (I’m attaching the traceback even though it’s >> not very helpful). Unfortunately, the error doesn’t say which symbol and >> from which library - and the use is inside Apple’s core library, not R >> itself - so I have to dig deeper to see what triggers it. This could well be >> some bug in R-devel, because the build of R-4.4-branch from the same nightly >> run works fine. I’ll try to have a more in-depth look next week. >> >> Cheers, >> Simon >> >> >> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT >> frame #0: 0x00000001972434c8 dyld`__abort_with_payload + 8 >> dyld`: >> -> 0x1972434c8 <+8>: b.lo 0x1972434e8 ; <+40> >> 0x1972434cc <+12>: pacibsp >> 0x1972434d0 <+16>: stp x29, x30, [sp, #-0x10]! >> 0x1972434d4 <+20>: mov x29, sp >> Target 0: (R) stopped. >> (lldb) bt >> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT >> * frame #0: 0x00000001972434c8 dyld`__abort_with_payload + 8 >> frame #1: 0x000000019724e0cc dyld`abort_with_payload_wrapper_internal + 104 >> frame #2: 0x000000019724e100 dyld`abort_with_payload + 16 >> frame #3: 0x00000001971df7f0 dyld`dyld4::halt(char const*, >> dyld4::StructuredError const*) + 304 >> frame #4: 0x00000001972144fc >> dyld`dyld4::APIs::_dyld_missing_symbol_abort() + 28 >> frame #5: 0x000000019879574c Foundation`__NSFireDelayedPerform + 372 >> frame #6: 0x00000001976615b8 >> CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 >> frame #7: 0x000000019766125c CoreFoundation`__CFRunLoopDoTimer + 972 >> frame #8: 0x0000000197660d94 CoreFoundation`__CFRunLoopDoTimers + 356 >> frame #9: 0x00000001976441cc CoreFoundation`__CFRunLoopRun + 1856 >> frame #10: 0x0000000197643434 CoreFoundation`CFRunLoopRunSpecific + 608 >> frame #11: 0x00000001a1ded19c HIToolbox`RunCurrentEventLoopInMode + 292 >> frame #12: 0x00000001a1decfd8 HIToolbox`ReceiveNextEventCommon + 648 >> frame #13: 0x00000001a1decd30 >> HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 >> frame #14: 0x000000019aea2cc8 AppKit`_DPSNextEvent + 660 >> frame #15: 0x000000019b6994d0 AppKit`-[NSApplication(NSEventRouting) >> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700 >> frame #16: 0x0000000100009628 R`-[RController doProcessEvents:] + 160 >> frame #17: 0x0000000100005260 R`-[RController handleReadConsole:] + 80 >> frame #18: 0x000000010000c0d8 R`Re_ReadConsole + 192 >> frame #19: 0x0000000100b76328 libR.dylib`R_ReplDLLdo1 at main.c:375:6 [opt] >> frame #20: 0x0000000100016ea0 R`run_REngineRmainloop + 260 >> frame #21: 0x000000010000e54c R`-[REngine runREPL] + 124 >> frame #22: 0x0000000100001c2c R`main + 592 >> frame #23: 0x00000001971db154 dyld`start + 2476 >> >> >> >> >> >> >>> On 26 Sep 2024, at 06:12, Sebastian Kreutzer >>> <sebastian.kreut...@uni-heidelberg.de> wrote: >>> >>> Hello, >>> >>> Thanks again to Prof Ripley and Simon; however, I am afraid I have to get >>> back >>> to you on this because my “I am good for now" was premature. >>> >>> The R-devel builds now appear again on https://mac.r-project.org/; thank >>> you very much! >>> >>> Unfortunately, I have the same issue with these builds as with the ones I >>> have produced locally. >>> >>> - I installed and tried the binary builds from >>> https://mac.r-project.org/big-sur/last-success/ and >>> https://mac.r-project.org/ but when I use RStudio (just updated before once >>> more) and try to load >>> a package, the session crashes immediately. The same goes for the R GUI; it >>> won’t start anymore. >>> >>> - As before, calling R from the terminal works fine without any issue >>> >>> - When I return to R-4.4.1-arm64.pkg (always freshly installed, no version >>> switching), >>> everything works as expected, with no error or issue. >>> >>> - I’ve looked up the RStudio GitHub issue list but found no report >>> >>> - The console shows the following errors (shorted; I can provide full >>> reports if wanted): >>> >>> RStudio: EXC_CRASH (SIGABRT) >>> R GUI: codes":"0x0000000000000000, >>> 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":”SIGABRT" >>> >>> - To be absolutely sure, I then tried to install the R-devel build from >>> https://mac.r-project.org/ on my private M1 Mac mini, still running macOS >>> 14.7 and >>> I got the same crashes. Other than being from Apple, these two machines >>> (the M2 and the private M1) have nothing in common >>> regarding the setup. >>> >>> This observation makes me somewhat think that it is likely that someone >>> else can perhaps reproduce this "issue"? >>> >>> Thanks once more for your support and kind regards, >>> >>> Sebastian >>> >>> P.S. Sorry for the HTML in my last messages. Prof Ripley was so kind as to >>> point me to the e-mail certificate that caused these HTML tags. It should >>> be fine now. >>> >>> >>>> On 25. Sep 2024, at 11:50, Prof Brian Ripley <rip...@stats.ox.ac.uk> wrote: >>>> >>>> On 25/09/2024 10:26, Sebastian Kreutzer wrote: >>>>> Hi Simon, >>>>> Many thanks for your prompt reply and the link; it greatly helps, and I >>>>> appreciate it! >>>>> Yes, sorry for not detailing my issue further, but I did not want to >>>>> spam anybody with the log and configuration files I am using, so I cut it >>>>> short. >>>>> I will also look more carefully into the differences between “my” build >>>>> process and the CRAN builds; >>>>> it seems evident that I have overlooked something. My initial thought was >>>>> just that with all the API >>>>> changes going on and me using a more recent version of macOS for the >>>>> build than CRAN does, >>>> >>>> The machine used for the M1mac additional issue is fully up-to-date, see >>>> https://www.stats.ox.ac.uk/pub/bdr/M1mac/README.txt >>>> >>>> Following the instructions in the R-admin manual and not by some third >>>> party is always a good idea before posting. >>>> >>>> Do please stop sending HTML, as required in the posting guide. >>>> >>>>> it would not surprise me that, at some point, something >>>>> had changed in macOS, causing this “user-interface-only” crash. >>>>> Anyway, so as not to bother you further, thanks again for the help. I am >>>>> good for now, >>>>> and if I figure out what has to be changed in my configuration to make it >>>>> work again, I will post it. >>>>> Kind regards, >>>>> Sebastian >>>>>> On 25. Sep 2024, at 01:40, Simon Urbanek <simon.urba...@r-project.org> >>>>>> wrote: >>>>>> >>>>>> Sebastian, >>>>>> >>>>>> if you want to replicate the CRAN builds, you have to also use the same >>>>>> settings, otherwise you may have a build which is not binary compatible. >>>>>> It is unclear from your description how you built R (there are several >>>>>> variants such as framework install vs "unix"-style install and they are >>>>>> incompatible). You can see the flags actually used at the top of >>>>>> ${R_HOME}/etc/Makevars. >>>>>> >>>>>> As for macOS R binaries, all latest builds are always available from >>>>>> https://mac.r-project.org/big-sur/last-success/ >>>>>> >>>>>> The fact that the main page itself is not showing R-devel is certainly >>>>>> not intentional since the binaries are there - I’ll look into that, >>>>>> thanks for reposting (you shouldn't wait months to report that ;)). >>>> >>>> I did report it a month ago to Simon. >>>> >>>>>> >>>>>> Thanks, >>>>>> Simon >>>>>> >>>>>> >>>>>> >>>>>>> On 24 Sep 2024, at 02:27, Sebastian Kreutzer <sebastian.kreutzer@uni- >>>>>>> heidelberg.de> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am writing because I have been struggling for a couple of months to >>>>>>> get R-devel to work in combination with >>>>>>> RStudio or the R GUI. >>>>>>> >>>>>>> In the past, I had been downloading R-devel for macOS from https:// >>>>>>> mac.r-project.org/, which >>>>>>> nearly always worked, however, for some (months I have in mind), there >>>>>>> aren't daily R-devel builds. So I started building >>>>>>> R from source following https://stackoverflow.com/questions/75595875/ >>>>>>> how-do-i-build-r-from-sources-on-macos >>>>>>> >>>>>>> Adapted to my system, this worked surprisingly well, so I kept drawing >>>>>>> R-devel from the SNV server on a regular >>>>>>> basis and built it from the source. However, it stopped working in >>>>>>> mid-August. In a nutshell: >>>>>>> >>>>>>> - I can build R-devel from the source without any issue flagged, and >>>>>>> when started in the terminal, it works as expected. >>>>>>> - However, it crashes reproducibly when trying to load a package in >>>>>>> RStudio (stable/nightly build) and the R GUI (always the latest version) >>>>>>> terminates the R session on start. Error messages in the console I get >>>>>>> read as follows: >>>>>>> >>>>>>>> R GUI: Termination Reason: Namespace SIGNAL, Code 11 Segmentation >>>>>>>> fault: 11 >>>>>>>> RStudio: Exception Type: EXC_CRASH (SIGABRT) -> /usr/lib/dyld 0x0 - >>>>>>>> 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ??? >>>>>>> >>>>>>> I can share the full logs, but I want to keep it short for now. >>>>>>> >>>>>>> My questions are: >>>>>>> >>>>>>> - Did anybody encounter such an issue with the latest R-devel and R >>>>>>> GUI, RStudio? >>>>>>> - Is this perhaps why an R-devel binary is currently not available on >>>>>>> https://mac.r-project.org/? >>>>>>> >>>>>>> If I know that this is a known issue, it is all good; however, if it >>>>>>> works >>>>>>> For all others without, then the error must be on my end, and I have to >>>>>>> keep digging further. >>>>>>> >>>>>>> - Tested systems: M2 -> macOS 14.5 to 15.0 with the Xcode on always the >>>>>>> latest version available at the time. >>>>>>> - SNV: Always the latest check out >>>>>>> >>>>>>> >>>>>>> Kind regards, >>>>>>> >>>>>>> >>>>>>> Sebastian Kreutzer >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> R-SIG-Mac mailing list >>>>> R-SIG-Mac@r-project.org >>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >>>> >>>> >>>> -- >>>> Brian D. Ripley, rip...@stats.ox.ac.uk >>>> Emeritus Professor of Applied Statistics, University of Oxford >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> R-SIG-Mac mailing list >>> R-SIG-Mac@r-project.org >>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >>> >> >> _______________________________________________ >> R-SIG-Mac mailing list >> R-SIG-Mac@r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> > [[alternative HTML version deleted]] _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
