Re: [R-SIG-Mac] R-devel segmentation fault in combination RStudio/R GUI
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 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 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: 0x0001972434c8 dyld`__abort_with_payload + 8 >> dyld`: >> -> 0x1972434c8 <+8>: b.lo 0x1972434e8 ; <+40> >> 0x1972434cc <+12>: pacibsp >> 0x1972434d0 <+16>: stpx29, x30, [sp, #-0x10]! >> 0x1972434d4 <+20>: movx29, sp >> Target 0: (R) stopped. >> (lldb) bt >> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT >> * frame #0: 0x0001972434c8 dyld`__abort_with_payload + 8 >> frame #1: 0x00019724e0cc dyld`abort_with_payload_wrapper_internal + 104 >> frame #2: 0x00019724e100 dyld`abort_with_payload + 16 >> frame #3: 0x0001971df7f0 dyld`dyld4::halt(char const*, >> dyld4::StructuredError const*) + 304 >> frame #4: 0x0001972144fc >> dyld`dyld4::APIs::_dyld_missing_symbol_abort() + 28 >> frame #5: 0x00019879574c Foundation`__NSFireDelayedPerform + 372 >> frame #6: 0x0001976615b8 >> CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 >> frame #7: 0x00019766125c CoreFoundation`__CFRunLoopDoTimer + 972 >> frame #8: 0x000197660d94 CoreFoundation`__CFRunLoopDoTimers + 356 >> frame #9: 0x0001976441cc CoreFoundation`__CFRunLoopRun + 1856 >> frame #10: 0x000197643434 CoreFoundation`CFRunLoopRunSpecific + 608 >> frame #11: 0x0001a1ded19c HIToolbox`RunCurrentEventLoopInMode + 292 >> frame #12: 0x0001a1decfd8 HIToolbox`ReceiveNextEventCommon + 648 >> frame #13: 0x0001a1decd30 >> HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 >> frame #14: 0x00019aea2cc8 AppKit`_DPSNextEvent + 660 >> frame #15: 0x00019b6994d0 AppKit`-[NSApplication(NSEventRouting) >> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700 >> frame #16: 0x00019628 R`-[RController doProcessEvents:] + 160 >> frame #17: 0x00015260 R`-[RController handleReadConsole:] + 80 >> frame #18: 0x0001c0d8 R`Re_ReadConsole + 192 >> frame #19: 0x000100b76328 libR.dylib`R_ReplDLLdo1 at main.c:375:6 [opt] >> frame #20: 0x000100016ea0 R`run_REngineRmainloop + 260 >> frame #21: 0x0001e54c R`-[REngine runREPL] + 124 >> frame #22: 0x00011c2c R`main + 592 >> frame #23: 0x0001971db154 dyld`start + 2476 >> >> >> >> >> >> >>> On 26 Sep 2024, at 06:12, Sebastian Kreutzer >>> 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), >>>
Re: [R-SIG-Mac] R-devel segmentation fault in combination RStudio/R GUI
[[alternative HTML version deleted]] ___ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] R-devel segmentation fault in combination RStudio/R GUI
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 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: 0x0001972434c8 dyld`__abort_with_payload + 8 > dyld`: > -> 0x1972434c8 <+8>: b.lo 0x1972434e8 ; <+40> >0x1972434cc <+12>: pacibsp >0x1972434d0 <+16>: stpx29, x30, [sp, #-0x10]! >0x1972434d4 <+20>: movx29, sp > Target 0: (R) stopped. > (lldb) bt > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT > * frame #0: 0x0001972434c8 dyld`__abort_with_payload + 8 >frame #1: 0x00019724e0cc dyld`abort_with_payload_wrapper_internal + 104 >frame #2: 0x00019724e100 dyld`abort_with_payload + 16 >frame #3: 0x0001971df7f0 dyld`dyld4::halt(char const*, > dyld4::StructuredError const*) + 304 >frame #4: 0x0001972144fc > dyld`dyld4::APIs::_dyld_missing_symbol_abort() + 28 >frame #5: 0x00019879574c Foundation`__NSFireDelayedPerform + 372 >frame #6: 0x0001976615b8 > CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 >frame #7: 0x00019766125c CoreFoundation`__CFRunLoopDoTimer + 972 >frame #8: 0x000197660d94 CoreFoundation`__CFRunLoopDoTimers + 356 >frame #9: 0x0001976441cc CoreFoundation`__CFRunLoopRun + 1856 >frame #10: 0x000197643434 CoreFoundation`CFRunLoopRunSpecific + 608 >frame #11: 0x0001a1ded19c HIToolbox`RunCurrentEventLoopInMode + 292 >frame #12: 0x0001a1decfd8 HIToolbox`ReceiveNextEventCommon + 648 >frame #13: 0x0001a1decd30 > HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 >frame #14: 0x00019aea2cc8 AppKit`_DPSNextEvent + 660 >frame #15: 0x00019b6994d0 AppKit`-[NSApplication(NSEventRouting) > _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700 >frame #16: 0x00019628 R`-[RController doProcessEvents:] + 160 >frame #17: 0x00015260 R`-[RController handleReadConsole:] + 80 >frame #18: 0x0001c0d8 R`Re_ReadConsole + 192 >frame #19: 0x000100b76328 libR.dylib`R_ReplDLLdo1 at main.c:375:6 [opt] >frame #20: 0x000100016ea0 R`run_REngineRmainloop + 260 >frame #21: 0x0001e54c R`-[REngine runREPL] + 124 >frame #22: 0x00011c2c R`main + 592 >frame #23: 0x0001971db154 dyld`start + 2476 > > > > > > >> On 26 Sep 2024, at 06:12, Sebastian Kreutzer >> 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":"0x, >> 0x","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
Re: [R-SIG-Mac] R-devel segmentation fault in combination RStudio/R GUI
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: 0x0001972434c8 dyld`__abort_with_payload + 8 dyld`: -> 0x1972434c8 <+8>: b.lo 0x1972434e8 ; <+40> 0x1972434cc <+12>: pacibsp 0x1972434d0 <+16>: stpx29, x30, [sp, #-0x10]! 0x1972434d4 <+20>: movx29, sp Target 0: (R) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x0001972434c8 dyld`__abort_with_payload + 8 frame #1: 0x00019724e0cc dyld`abort_with_payload_wrapper_internal + 104 frame #2: 0x00019724e100 dyld`abort_with_payload + 16 frame #3: 0x0001971df7f0 dyld`dyld4::halt(char const*, dyld4::StructuredError const*) + 304 frame #4: 0x0001972144fc dyld`dyld4::APIs::_dyld_missing_symbol_abort() + 28 frame #5: 0x00019879574c Foundation`__NSFireDelayedPerform + 372 frame #6: 0x0001976615b8 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 frame #7: 0x00019766125c CoreFoundation`__CFRunLoopDoTimer + 972 frame #8: 0x000197660d94 CoreFoundation`__CFRunLoopDoTimers + 356 frame #9: 0x0001976441cc CoreFoundation`__CFRunLoopRun + 1856 frame #10: 0x000197643434 CoreFoundation`CFRunLoopRunSpecific + 608 frame #11: 0x0001a1ded19c HIToolbox`RunCurrentEventLoopInMode + 292 frame #12: 0x0001a1decfd8 HIToolbox`ReceiveNextEventCommon + 648 frame #13: 0x0001a1decd30 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 frame #14: 0x00019aea2cc8 AppKit`_DPSNextEvent + 660 frame #15: 0x00019b6994d0 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700 frame #16: 0x00019628 R`-[RController doProcessEvents:] + 160 frame #17: 0x00015260 R`-[RController handleReadConsole:] + 80 frame #18: 0x0001c0d8 R`Re_ReadConsole + 192 frame #19: 0x000100b76328 libR.dylib`R_ReplDLLdo1 at main.c:375:6 [opt] frame #20: 0x000100016ea0 R`run_REngineRmainloop + 260 frame #21: 0x0001e54c R`-[REngine runREPL] + 124 frame #22: 0x00011c2c R`main + 592 frame #23: 0x0001971db154 dyld`start + 2476 > On 26 Sep 2024, at 06:12, Sebastian Kreutzer > 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":"0x, > 0x","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 wrote: >> >> On 25/09/2024 10:26, Sebastian Kreutzer wrote: >>> Hi Simon, >>> Many thanks for your prompt reply and the link; it greatly helps,
Re: [R-SIG-Mac] R-devel segmentation fault in combination RStudio/R GUI
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":"0x,
0x","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 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
>>> 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 >>> 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
Re: [R-SIG-Mac] R-devel segmentation fault in combination RStudio/R GUI
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
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 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
- 0x ??? (*) <----> ???
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
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Brian D. Ripley, [email protected]
Emeritus Professor of Applied Statistics, University of Oxford
___
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] R-devel segmentation fault in combination RStudio/R GUI
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,
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 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 ;)).
>
> Thanks,
> Simon
>
>
>
>> On 24 Sep 2024, at 02:27, Sebastian Kreutzer
>> 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 -
>>> 0x ??? (*) <----> ???
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
smime.p7s
Description: S/MIME cryptographic signature
___
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] R-devel segmentation fault in combination RStudio/R GUI
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 ;)).
Thanks,
Simon
> On 24 Sep 2024, at 02:27, Sebastian Kreutzer
> 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 -
>> 0x ??? (*) <----> ???
>
> 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
> [email protected]
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
