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
