[R-SIG-Mac] R-devel segmentation fault in combination RStudio/R GUI
Sebastian Kreutzer
@eb@@t|@n@kreutzer @end|ng |rom un|-he|de|berg@de
Thu Sep 26 10:51:00 CEST 2024
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.urbanek using 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.urbanek using 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.kreutzer using 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 <ripley using 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.urbanek using 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 using 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 using r-project.org
>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>
>>>>
>>>> --
>>>> Brian D. Ripley, ripley using stats.ox.ac.uk
>>>> Emeritus Professor of Applied Statistics, University of Oxford
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac using r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>
[[alternative HTML version deleted]]
More information about the R-SIG-Mac
mailing list