From @|mon@urb@nek @end|ng |rom R-project@org Thu Jul 2 07:27:37 2020 From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) Date: Thu, 2 Jul 2020 17:27:37 +1200 Subject: [R-SIG-Mac] Can't open files in 4.0 or 4.01 In-Reply-To: References: <9068383e-c7d2-3700-7cc6-cc6efd845dfb@witthoft.com> <358EBEC9-BD61-49DD-A3FE-6A54E89DF8FC@rud.is> <33CD8F07-3356-4079-98D7-E3A4E8909B3A@R-project.org> <38891D68-5A9A-45D1-B123-67AAE8BC1E23@R-project.org> <474a1448-873c-6aaa-2d15-13467c7390bb@witthoft.com> <4B877A47-2925-4786-BEAB-33D7BF3807FD@R-project.org> <2EE25273-B51B-4151-A62F-5CF6463FC56C@mac.com> <2A047816-4553-4A53-8B57-117ED14366F3@r-project.org> Message-ID: Thanks to all, much appreciated. Please try the latest GUI revision 7849 from https://mac.R-project.org The issue I found so far seems to have to do with function folding in documents - which is why is actually depends on the document content - and a selector that is apparently missing in Catalina. Thanks, Simon > On 29/06/2020, at 11:22 AM, Brandon Hurr wrote: > > Simon. > Default changed, RGUI 7846 Debug downloaded and run on same scripts. > > Crash report here; > https://gist.github.com/bhive01/fd844404ef3e1d295036e5abd127864b > > Let me know if you need more reports or to try something else. > > Brandon > > On Sun, Jun 28, 2020 at 4:00 PM Simon Urbanek > wrote: > >> Brandon, >> >> Yes, this is of great help! It shows the the GUI spins in the segfault >> handler (it segfaults while rendering text which calls the R segfault >> handler which in turn tries to render more text etc. ...). >> So first thing is to avoid the signal handler, run this command in >> Terminal: >> >> defaults write org.R-project.R 'Disable R signal handlers' YES >> >> Then download the debug version of the R GUI from >> >> https://mac.R-project.org/ >> >> where it says Mac OS X GUI ... high-sierra-Debug.dmg - pick the one >> matching your R version (4.0 for release or 4.1 for R-devel). You don't >> need to replace your regular one, you can run it simply from the image. >> Note that it is signed, but not notarized, so right-click (=ctrl-click) on >> it and select "Open". >> >> That will avoid the "hang" but will give a proper segfault with an Apple >> report so won't help immediately but will make it easier to pinpoint. Also >> it should include debug symbols with line numbers and all that. Please post >> the crash report. >> >> Thank you for your help, >> Simon >> >> >> >>> On Jun 29, 2020, at 4:25 AM, Brandon Hurr >> wrote: >>> >>> Thanks Ben. >>> >>> I fired up R did a 20 second sample as I loaded files and it went into a >> hang. >>> https://gist.github.com/bhive01/77ccd888da1ee74da12a5c91cfc3d727 >>> >>> Seems to have the symbols you describe. Is that more helpful? >>> >>> Brandon >> >> > > [[alternative HTML version deleted]] > > _______________________________________________ > R-SIG-Mac mailing list > R-SIG-Mac at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-mac From c@r| @end|ng |rom w|ttho|t@com Thu Jul 2 14:55:30 2020 From: c@r| @end|ng |rom w|ttho|t@com (Carl Witthoft) Date: Thu, 2 Jul 2020 08:55:30 -0400 Subject: [R-SIG-Mac] Can't open files in 4.0 or 4.01 In-Reply-To: References: <9068383e-c7d2-3700-7cc6-cc6efd845dfb@witthoft.com> <358EBEC9-BD61-49DD-A3FE-6A54E89DF8FC@rud.is> <33CD8F07-3356-4079-98D7-E3A4E8909B3A@R-project.org> <38891D68-5A9A-45D1-B123-67AAE8BC1E23@R-project.org> <474a1448-873c-6aaa-2d15-13467c7390bb@witthoft.com> <4B877A47-2925-4786-BEAB-33D7BF3807FD@R-project.org> <2EE25273-B51B-4151-A62F-5CF6463FC56C@mac.com> <2A047816-4553-4A53-8B57-117ED14366F3@r-project.org> Message-ID: Hi, I ran 7849 high sierra debug GUI, and am happy to report that I had zero crashes or hangs. I tried opening via the icon in the console window, from the File menu, and even by selecting a dozen "name.r" files in the Finder and hitting -O . All files opened, no problems seen. On 7/2/20 1:27 AM, Simon Urbanek wrote: > Thanks to all, much appreciated. Please try the latest GUI revision 7849 from https://mac.R-project.org > The issue I found so far seems to have to do with function folding in documents - which is why is actually depends on the document content - and a selector that is apparently missing in Catalina. > > Thanks, > Simon > > >> On 29/06/2020, at 11:22 AM, Brandon Hurr wrote: >> >> Simon. >> Default changed, RGUI 7846 Debug downloaded and run on same scripts. >> >> Crash report here; >> https://gist.github.com/bhive01/fd844404ef3e1d295036e5abd127864b >> >> Let me know if you need more reports or to try something else. >> >> Brandon >> >> On Sun, Jun 28, 2020 at 4:00 PM Simon Urbanek >> wrote: >> >>> Brandon, >>> >>> Yes, this is of great help! It shows the the GUI spins in the segfault >>> handler (it segfaults while rendering text which calls the R segfault >>> handler which in turn tries to render more text etc. ...). >>> So first thing is to avoid the signal handler, run this command in >>> Terminal: >>> >>> defaults write org.R-project.R 'Disable R signal handlers' YES >>> >>> Then download the debug version of the R GUI from >>> >>> https://mac.R-project.org/ >>> >>> where it says Mac OS X GUI ... high-sierra-Debug.dmg - pick the one >>> matching your R version (4.0 for release or 4.1 for R-devel). You don't >>> need to replace your regular one, you can run it simply from the image. >>> Note that it is signed, but not notarized, so right-click (=ctrl-click) on >>> it and select "Open". >>> >>> That will avoid the "hang" but will give a proper segfault with an Apple >>> report so won't help immediately but will make it easier to pinpoint. Also >>> it should include debug symbols with line numbers and all that. Please post >>> the crash report. >>> >>> Thank you for your help, >>> Simon >>> >>> >>> >>>> On Jun 29, 2020, at 4:25 AM, Brandon Hurr >>> wrote: >>>> >>>> Thanks Ben. >>>> >>>> I fired up R did a 20 second sample as I loaded files and it went into a >>> hang. >>>> https://gist.github.com/bhive01/77ccd888da1ee74da12a5c91cfc3d727 >>>> >>>> Seems to have the symbols you describe. Is that more helpful? >>>> >>>> Brandon >>> >>> >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> R-SIG-Mac mailing list >> R-SIG-Mac at r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac > -- Carl Witthoft carl at witthoft.com resume: https://app.box.com/file/498153801347 From br@ndon@hurr @end|ng |rom gm@||@com Thu Jul 2 16:14:19 2020 From: br@ndon@hurr @end|ng |rom gm@||@com (Brandon Hurr) Date: Thu, 2 Jul 2020 07:14:19 -0700 Subject: [R-SIG-Mac] Can't open files in 4.0 or 4.01 In-Reply-To: References: <9068383e-c7d2-3700-7cc6-cc6efd845dfb@witthoft.com> <358EBEC9-BD61-49DD-A3FE-6A54E89DF8FC@rud.is> <33CD8F07-3356-4079-98D7-E3A4E8909B3A@R-project.org> <38891D68-5A9A-45D1-B123-67AAE8BC1E23@R-project.org> <474a1448-873c-6aaa-2d15-13467c7390bb@witthoft.com> <4B877A47-2925-4786-BEAB-33D7BF3807FD@R-project.org> <2EE25273-B51B-4151-A62F-5CF6463FC56C@mac.com> <2A047816-4553-4A53-8B57-117ED14366F3@r-project.org> Message-ID: Simon, I can happily report the same for me after opening over a dozen R scripts with lots of functions in them. Code folding is working fine as well. Thanks so much for sticking with us on this. Cheers, Brandon On Thu, Jul 2, 2020 at 5:55 AM Carl Witthoft wrote: > Hi, I ran 7849 high sierra debug GUI, > > and am happy to report that I had zero crashes or hangs. > > I tried opening via the icon in the console window, from the File menu, > and even by selecting a dozen "name.r" files in the Finder and hitting > -O . All files opened, no problems seen. > > On 7/2/20 1:27 AM, Simon Urbanek wrote: > > Thanks to all, much appreciated. Please try the latest GUI revision 7849 > from https://mac.R-project.org > > The issue I found so far seems to have to do with function folding in > documents - which is why is actually depends on the document content - and > a selector that is apparently missing in Catalina. > > > > Thanks, > > Simon > > > > > >> On 29/06/2020, at 11:22 AM, Brandon Hurr > wrote: > >> > >> Simon. > >> Default changed, RGUI 7846 Debug downloaded and run on same scripts. > >> > >> Crash report here; > >> https://gist.github.com/bhive01/fd844404ef3e1d295036e5abd127864b > >> > >> Let me know if you need more reports or to try something else. > >> > >> Brandon > >> > >> On Sun, Jun 28, 2020 at 4:00 PM Simon Urbanek < > simon.urbanek at r-project.org> > >> wrote: > >> > >>> Brandon, > >>> > >>> Yes, this is of great help! It shows the the GUI spins in the segfault > >>> handler (it segfaults while rendering text which calls the R segfault > >>> handler which in turn tries to render more text etc. ...). > >>> So first thing is to avoid the signal handler, run this command in > >>> Terminal: > >>> > >>> defaults write org.R-project.R 'Disable R signal handlers' YES > >>> > >>> Then download the debug version of the R GUI from > >>> > >>> https://mac.R-project.org/ > >>> > >>> where it says Mac OS X GUI ... high-sierra-Debug.dmg - pick the one > >>> matching your R version (4.0 for release or 4.1 for R-devel). You don't > >>> need to replace your regular one, you can run it simply from the image. > >>> Note that it is signed, but not notarized, so right-click > (=ctrl-click) on > >>> it and select "Open". > >>> > >>> That will avoid the "hang" but will give a proper segfault with an > Apple > >>> report so won't help immediately but will make it easier to pinpoint. > Also > >>> it should include debug symbols with line numbers and all that. Please > post > >>> the crash report. > >>> > >>> Thank you for your help, > >>> Simon > >>> > >>> > >>> > >>>> On Jun 29, 2020, at 4:25 AM, Brandon Hurr > >>> wrote: > >>>> > >>>> Thanks Ben. > >>>> > >>>> I fired up R did a 20 second sample as I loaded files and it went > into a > >>> hang. > >>>> https://gist.github.com/bhive01/77ccd888da1ee74da12a5c91cfc3d727 > >>>> > >>>> Seems to have the symbols you describe. Is that more helpful? > >>>> > >>>> Brandon > >>> > >>> > >> > >> [[alternative HTML version deleted]] > >> > >> _______________________________________________ > >> R-SIG-Mac mailing list > >> R-SIG-Mac at r-project.org > >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > > > -- > Carl Witthoft > carl at witthoft.com > resume: https://app.box.com/file/498153801347 > [[alternative HTML version deleted]] From @e||v@nov@dm|tr|y @end|ng |rom gm@||@com Wed Jul 8 13:08:06 2020 From: @e||v@nov@dm|tr|y @end|ng |rom gm@||@com (Dmitriy Selivanov) Date: Wed, 8 Jul 2020 15:08:06 +0400 Subject: [R-SIG-Mac] Advise on building R on OSX without optimization for debugging Message-ID: Dear all, I'm trying to debug a segfault reported here https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17850 (thanks Kevin for the nice article https://kevinushey.github.io/blog/2015/04/13/debugging-with-lldb/ about debugging with lldb) I need to compile R without optimization (with the O0 flag) instead of using binaries provided by Simon. Here I have difficulties. What I've tried: 1. Downloaded latest R-devel from https://stat.ethz.ch/R/daily/R-devel.tar.gz 2. Downloaded xz and pcre2 as suggested here https://mac.r-project.org/tools/ 3. run ./confilgure 4. replaced O2 with O0 in Makeconf 5. make Now R is compiled and I can launch it with ./bin/R. However when I run it with lldb 1. ./bin/R -d lldb 2. run I'm, getting: Process 74482 launched: '/Users/dmitry.selivanov/Downloads/R-devel/bin/exec/R' (x86_64) dyld: Library not loaded: libRblas.dylib Referenced from: /Users/dmitry.selivanov/Downloads/R-devel/bin/exec/R Reason: image not found Process 74482 stopped * thread #1, stop reason = signal SIGABRT frame #0: 0x0000000100574ebe dyld`__abort_with_payload + 10 dyld`__abort_with_payload: -> 0x100574ebe <+10>: jae 0x100574ec8 ; <+20> 0x100574ec0 <+12>: movq %rax, %rdi 0x100574ec3 <+15>: jmp 0x1005733e8 ; cerror_nocancel 0x100574ec8 <+20>: retq Target 0: (R) stopped. Any suggestions? Things are much easier on linux-based docker images, but I can't reproduce the reported bug there... Regards Dmitriy Selivanov [[alternative HTML version deleted]] From @|mon@urb@nek @end|ng |rom R-project@org Wed Jul 8 22:38:56 2020 From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) Date: Thu, 9 Jul 2020 08:38:56 +1200 Subject: [R-SIG-Mac] Advise on building R on OSX without optimization for debugging In-Reply-To: References: Message-ID: <1812A202-F83B-42B5-BBE6-58FFC52FD133@R-project.org> Dmitriy, due to permissions and the various limitations on passing environment variables across processes it is often easier to simply run R and attach the debugger to it: $ R [...] > Sys.getpid() [1] 89955 > $ sudo lldb Password: (lldb) attach 89955 [...] (lldb) c Process 89955 resuming Also note that you shouldn't change Makeconf by hand, simply supply any CFLAGS you need to configure, e.g.: ../R-devel/configure --enable-R-shlib 'CFLAGS=-Wall -g -O0' 'CXXFLAGS=-Wall -g -O0' Cheers, Simon > On Jul 8, 2020, at 11:08 PM, Dmitriy Selivanov wrote: > > Dear all, > > I'm trying to debug a segfault reported here > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17850 (thanks Kevin for > the nice article > https://kevinushey.github.io/blog/2015/04/13/debugging-with-lldb/ about > debugging with lldb) > > I need to compile R without optimization (with the O0 flag) instead of > using binaries provided by Simon. > > Here I have difficulties. What I've tried: > > 1. Downloaded latest R-devel from > https://stat.ethz.ch/R/daily/R-devel.tar.gz > 2. Downloaded xz and pcre2 as suggested here > https://mac.r-project.org/tools/ > 3. run ./confilgure > 4. replaced O2 with O0 in Makeconf > 5. make > > Now R is compiled and I can launch it with ./bin/R. However when I run it > with lldb > > 1. ./bin/R -d lldb > 2. run > > I'm, getting: > > Process 74482 launched: > '/Users/dmitry.selivanov/Downloads/R-devel/bin/exec/R' (x86_64) > > dyld: Library not loaded: libRblas.dylib > > Referenced from: /Users/dmitry.selivanov/Downloads/R-devel/bin/exec/R > > Reason: image not found > > Process 74482 stopped > > * thread #1, stop reason = signal SIGABRT > > frame #0: 0x0000000100574ebe dyld`__abort_with_payload + 10 > > dyld`__abort_with_payload: > > -> 0x100574ebe <+10>: jae 0x100574ec8 ; <+20> > > 0x100574ec0 <+12>: movq %rax, %rdi > > 0x100574ec3 <+15>: jmp 0x1005733e8 ; cerror_nocancel > > 0x100574ec8 <+20>: retq > > Target 0: (R) stopped. > > > Any suggestions? Things are much easier on linux-based docker images, but I > can't reproduce the reported bug there... > > > Regards > Dmitriy Selivanov > > [[alternative HTML version deleted]] > > _______________________________________________ > R-SIG-Mac mailing list > R-SIG-Mac at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > From @e||v@nov@dm|tr|y @end|ng |rom gm@||@com Thu Jul 9 13:46:52 2020 From: @e||v@nov@dm|tr|y @end|ng |rom gm@||@com (Dmitriy Selivanov) Date: Thu, 9 Jul 2020 15:46:52 +0400 Subject: [R-SIG-Mac] Advise on building R on OSX without optimization for debugging In-Reply-To: <1812A202-F83B-42B5-BBE6-58FFC52FD133@R-project.org> References: <1812A202-F83B-42B5-BBE6-58FFC52FD133@R-project.org> Message-ID: Thanks, Simon, That helped a lot and I was able to debug the error. Also I got another advice in a private email from Rodney Sparapani where he suggested making symlinks to libRblas.dylib, libR.dylib in the workdir. That worked as well. On Thu, Jul 9, 2020 at 1:16 AM Simon Urbanek wrote: > Dmitriy, > > due to permissions and the various limitations on passing environment > variables across processes it is often easier to simply run R and attach > the debugger to it: > > $ R > [...] > > Sys.getpid() > [1] 89955 > > > > $ sudo lldb > Password: > (lldb) attach 89955 > [...] > (lldb) c > Process 89955 resuming > > Also note that you shouldn't change Makeconf by hand, simply supply any > CFLAGS you need to configure, e.g.: > > ../R-devel/configure --enable-R-shlib 'CFLAGS=-Wall -g -O0' > 'CXXFLAGS=-Wall -g -O0' > > Cheers, > Simon > > > > On Jul 8, 2020, at 11:08 PM, Dmitriy Selivanov < > selivanov.dmitriy at gmail.com> wrote: > > > > Dear all, > > > > I'm trying to debug a segfault reported here > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17850 (thanks Kevin > for > > the nice article > > https://kevinushey.github.io/blog/2015/04/13/debugging-with-lldb/ about > > debugging with lldb) > > > > I need to compile R without optimization (with the O0 flag) instead of > > using binaries provided by Simon. > > > > Here I have difficulties. What I've tried: > > > > 1. Downloaded latest R-devel from > > https://stat.ethz.ch/R/daily/R-devel.tar.gz > > 2. Downloaded xz and pcre2 as suggested here > > https://mac.r-project.org/tools/ > > 3. run ./confilgure > > 4. replaced O2 with O0 in Makeconf > > 5. make > > > > Now R is compiled and I can launch it with ./bin/R. However when I run it > > with lldb > > > > 1. ./bin/R -d lldb > > 2. run > > > > I'm, getting: > > > > Process 74482 launched: > > '/Users/dmitry.selivanov/Downloads/R-devel/bin/exec/R' (x86_64) > > > > dyld: Library not loaded: libRblas.dylib > > > > Referenced from: /Users/dmitry.selivanov/Downloads/R-devel/bin/exec/R > > > > Reason: image not found > > > > Process 74482 stopped > > > > * thread #1, stop reason = signal SIGABRT > > > > frame #0: 0x0000000100574ebe dyld`__abort_with_payload + 10 > > > > dyld`__abort_with_payload: > > > > -> 0x100574ebe <+10>: jae 0x100574ec8 ; <+20> > > > > 0x100574ec0 <+12>: movq %rax, %rdi > > > > 0x100574ec3 <+15>: jmp 0x1005733e8 ; cerror_nocancel > > > > 0x100574ec8 <+20>: retq > > > > Target 0: (R) stopped. > > > > > > Any suggestions? Things are much easier on linux-based docker images, > but I > > can't reproduce the reported bug there... > > > > > > Regards > > Dmitriy Selivanov > > > > [[alternative HTML version deleted]] > > > > _______________________________________________ > > R-SIG-Mac mailing list > > R-SIG-Mac at r-project.org > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > > > -- Regards Dmitriy Selivanov [[alternative HTML version deleted]] From r|p|ey @end|ng |rom @t@t@@ox@@c@uk Mon Jul 13 09:59:11 2020 From: r|p|ey @end|ng |rom @t@t@@ox@@c@uk (Prof Brian Ripley) Date: Mon, 13 Jul 2020 08:59:11 +0100 Subject: [R-SIG-Mac] Advise on building R on OSX without optimization for debugging In-Reply-To: <1812A202-F83B-42B5-BBE6-58FFC52FD133@R-project.org> References: <1812A202-F83B-42B5-BBE6-58FFC52FD133@R-project.org> Message-ID: <7047b2c5-f6e7-3a4d-1f86-53653bb5a5d2@stats.ox.ac.uk> On 08/07/2020 21:38, Simon Urbanek wrote: > Dmitriy, > > due to permissions and the various limitations on passing environment variables across processes it is often easier to simply run R and attach the debugger to it: > > $ R > [...] >> Sys.getpid() > [1] 89955 >> > > $ sudo lldb > Password: > (lldb) attach 89955 > [...] > (lldb) c > Process 89955 resuming On Catalina I can do that for a version of R I compiled, but not for a notarized binary distribution (which also refuses to be run under a debugger). The lldb error message is maximally uninformative: (lldb) attach 16682 error: attach failed: Error 1 or (lldb) run error: process exited with status -1 (Error 1) I presume that is intentional on Apple's part and there is no way round it other than weakening security (e.g. disable SIP)? My memory was that it did work on High Sierra (I sometimes use it to investigate packages which segfault under your distribution but not with my builds) and I have just re-checked there with the CRAN distribution of 4.0.2. Brian Ripley -- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford From @|mon@urb@nek @end|ng |rom R-project@org Mon Jul 13 12:14:19 2020 From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) Date: Mon, 13 Jul 2020 22:14:19 +1200 Subject: [R-SIG-Mac] Advise on building R on OSX without optimization for debugging In-Reply-To: <7047b2c5-f6e7-3a4d-1f86-53653bb5a5d2@stats.ox.ac.uk> References: <1812A202-F83B-42B5-BBE6-58FFC52FD133@R-project.org> <7047b2c5-f6e7-3a4d-1f86-53653bb5a5d2@stats.ox.ac.uk> Message-ID: > On Jul 13, 2020, at 7:59 PM, Prof Brian Ripley wrote: > > On 08/07/2020 21:38, Simon Urbanek wrote: >> Dmitriy, >> due to permissions and the various limitations on passing environment variables across processes it is often easier to simply run R and attach the debugger to it: >> $ R >> [...] >>> Sys.getpid() >> [1] 89955 >>> >> $ sudo lldb >> Password: >> (lldb) attach 89955 >> [...] >> (lldb) c >> Process 89955 resuming > > On Catalina I can do that for a version of R I compiled, but not for a notarized binary distribution (which also refuses to be run under a debugger). The lldb error message is maximally uninformative: > > (lldb) attach 16682 > error: attach failed: Error 1 > > or > > (lldb) run > error: process exited with status -1 (Error 1) > > I presume that is intentional on Apple's part and there is no way round it other than weakening security (e.g. disable SIP)? > Correct. It is annoying enough that it made to to the FAQ: https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#I-cannot-attach-debugger-to-R So the recommended way is to use the non-notarised builds (you can also disable SIP but that is not recommended). And, yes, it would be nice if lldb provided a more useful error... I suspect that it would be actually sufficient to provide just a exec/R binary that doesn't use hardened run-time, but it couldn't be distributed in the Apple Installer ... unless we create it with the post install script ... something to test I suppose... Best, Simon > My memory was that it did work on High Sierra (I sometimes use it to investigate packages which segfault under your distribution but not with my builds) and I have just re-checked there with the CRAN distribution of 4.0.2. > > Brian Ripley > > -- > Brian D. Ripley, ripley at stats.ox.ac.uk > Emeritus Professor of Applied Statistics, University of Oxford > > _______________________________________________ > R-SIG-Mac mailing list > R-SIG-Mac at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-mac From r|p|ey @end|ng |rom @t@t@@ox@@c@uk Mon Jul 13 12:29:52 2020 From: r|p|ey @end|ng |rom @t@t@@ox@@c@uk (Prof Brian Ripley) Date: Mon, 13 Jul 2020 11:29:52 +0100 Subject: [R-SIG-Mac] Advise on building R on OSX without optimization for debugging In-Reply-To: References: <1812A202-F83B-42B5-BBE6-58FFC52FD133@R-project.org> <7047b2c5-f6e7-3a4d-1f86-53653bb5a5d2@stats.ox.ac.uk> Message-ID: <252d72a0-d56f-4e4b-bf45-9847cb4cf7bf@stats.ox.ac.uk> On 13/07/2020 11:14, Simon Urbanek wrote: > > >> On Jul 13, 2020, at 7:59 PM, Prof Brian Ripley wrote: >> >> On 08/07/2020 21:38, Simon Urbanek wrote: >>> Dmitriy, >>> due to permissions and the various limitations on passing environment variables across processes it is often easier to simply run R and attach the debugger to it: >>> $ R >>> [...] >>>> Sys.getpid() >>> [1] 89955 >>>> >>> $ sudo lldb >>> Password: >>> (lldb) attach 89955 >>> [...] >>> (lldb) c >>> Process 89955 resuming >> >> On Catalina I can do that for a version of R I compiled, but not for a notarized binary distribution (which also refuses to be run under a debugger). The lldb error message is maximally uninformative: >> >> (lldb) attach 16682 >> error: attach failed: Error 1 >> >> or >> >> (lldb) run >> error: process exited with status -1 (Error 1) >> >> I presume that is intentional on Apple's part and there is no way round it other than weakening security (e.g. disable SIP)? >> > > > Correct. It is annoying enough that it made to to the FAQ: > > https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#I-cannot-attach-debugger-to-R > > So the recommended way is to use the non-notarised builds (you can also disable SIP but that is not recommended). And, yes, it would be nice if lldb provided a more useful error... > > I suspect that it would be actually sufficient to provide just a exec/R binary that doesn't use hardened run-time, but it couldn't be distributed in the Apple Installer ... unless we create it with the post install script ... something to test I suppose... Thanks. My issues have been when my own build works but yours does not but while I am still checking on High Sierra I have workarounds. AFAIR the issues have all been array overruns which only sometimes cause segfaults. > Best, > Simon > > > > >> My memory was that it did work on High Sierra (I sometimes use it to investigate packages which segfault under your distribution but not with my builds) and I have just re-checked there with the CRAN distribution of 4.0.2. >> >> Brian Ripley >> >> -- >> Brian D. Ripley, ripley at stats.ox.ac.uk >> Emeritus Professor of Applied Statistics, University of Oxford >> >> _______________________________________________ >> R-SIG-Mac mailing list >> R-SIG-Mac at r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac > -- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford From j@me@@|@he@ter @end|ng |rom gm@||@com Mon Jul 13 17:00:03 2020 From: j@me@@|@he@ter @end|ng |rom gm@||@com (Jim Hester) Date: Mon, 13 Jul 2020 11:00:03 -0400 Subject: [R-SIG-Mac] R-devel daily build lagging Message-ID: It seems currently (as of 2020-07-13 the last daily build of R-devel was on 2020-07-01. (https://mac.r-project.org/) This seemed like a larger lag than normal since the last build. Just wondering if there was something wrong with the build machine, or if there was another reason for the delay. Jim [[alternative HTML version deleted]] From @|mon@urb@nek @end|ng |rom R-project@org Tue Jul 14 01:58:33 2020 From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) Date: Tue, 14 Jul 2020 11:58:33 +1200 Subject: [R-SIG-Mac] R-devel daily build lagging In-Reply-To: References: Message-ID: <646EE2F6-864D-4312-BDA4-7B5A37F92A8C@R-project.org> Jim, thanks, yes, you're right, the high-sierra nightly R-devel builds were suspended while I was re-working the package build system (it's all a bit more complex due to the legacy builds on El Capitan). I was re-building all the new VMs on the new hardware, and as of today we're finally on the latest build servers. This is mainly relevant for packages as that is the major load and has the highest complexity. So going forward everything should be back on the nightly schedule and there should be no lag anymore. If there is, please let me know. I'm wondering if it would make sense to have a parallel setup at least for R build using GH Actions or something similar. It wouldn't be signed nor notarized, so the real reason I'm asking is what do you use the nightly builds for? If it's for development then unsigned nightly tar balls would be ok, but it wouldn't be used for users as they need at the very least signed binaries. The benefit of that is that it could be fully automated on GitHub so others could fork it or use for their builds if needed. Cheers, Simon > On 14/07/2020, at 3:00 AM, Jim Hester wrote: > > It seems currently (as of 2020-07-13 the last daily build of R-devel was on > 2020-07-01. (https://mac.r-project.org/) > > This seemed like a larger lag than normal since the last build. > > Just wondering if there was something wrong with the build machine, or if > there was another reason for the delay. > > Jim > > [[alternative HTML version deleted]] > > _______________________________________________ > R-SIG-Mac mailing list > R-SIG-Mac at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-mac From r|p|ey @end|ng |rom @t@t@@ox@@c@uk Tue Jul 14 16:22:33 2020 From: r|p|ey @end|ng |rom @t@t@@ox@@c@uk (Prof Brian Ripley) Date: Tue, 14 Jul 2020 15:22:33 +0100 Subject: [R-SIG-Mac] Link-Time Optimization (LTO) Message-ID: This is a rather technical post about how libraries of compiled code can be further optimized. LTO generally produces smaller[*] and faster code (typically by a few percent) at the expense of increased installation time and is being used for large projects such as browsers and soon for some Linux distributions. I have committed a series of enhancements to LTO support in R-devel and will shortly port the more important of these to R-patched. This includes pretty comprehensive LTO support for clang, mainly to make LTO usable on macOS. (LLVM/clang has diverged considerably from GCC in how LTO is implemented - in particular with 'Thin LTO'.) Full details (including example settings for macOS) are in the R-admin manual. I would not use LTO on macOS routinely (I do on Linux), but for some applications the performance gains[+] maybe valuable enough. By the time R 4.1.0 is released it may be worth using it for the distributed R and binary packages LTO can be used to find inconsistencies between C/C++ compilation units as reported in the CRAN LTO 'Additional issues'. Unfortunately it cannot help with the more common C/Fortran inconsistencies as the intermediate representation used by gfortran is different and ignored by the macOS linker. An LLVM-based Fortran compiler (variously called flang and f18) has been promised for years but is being re-implemented and is far from usable. [*] although probably due to inlining, sometimes larger as it is for libR.dylib. [+] some R test scripts show negligible change in performance, several a gain of 5% and a couple a gain of 10-15%. Installation times depend rather a lot on how much one can make use of multithreading: on my dual-core MBP total R build elapsed time increased from 7:13 to 8:04 (m:s). -- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford From jeroenoom@ @end|ng |rom gm@||@com Wed Jul 15 10:50:49 2020 From: jeroenoom@ @end|ng |rom gm@||@com (Jeroen Ooms) Date: Wed, 15 Jul 2020 10:50:49 +0200 Subject: [R-SIG-Mac] Link-Time Optimization (LTO) In-Reply-To: References: Message-ID: On Tue, Jul 14, 2020 at 4:22 PM Prof Brian Ripley wrote: > > This is a rather technical post about how libraries of compiled code can > be further optimized. LTO generally produces smaller[*] and faster code > (typically by a few percent) at the expense of increased installation > time and is being used for large projects such as browsers and soon for > some Linux distributions. > > I have committed a series of enhancements to LTO support in R-devel and > will shortly port the more important of these to R-patched. Would it be worthwhile looking into this for Windows? We did enable support for LTO in the rtools40 toolchains*, but those are gcc-8.3.0 and some of the benefits require gcc-9. * https://github.com/r-windows/rtools-packages/blob/master/mingw-w64-gcc/PKGBUILD#L166 From r|p|ey @end|ng |rom @t@t@@ox@@c@uk Wed Jul 15 12:22:22 2020 From: r|p|ey @end|ng |rom @t@t@@ox@@c@uk (Prof Brian Ripley) Date: Wed, 15 Jul 2020 11:22:22 +0100 Subject: [R-SIG-Mac] Link-Time Optimization (LTO) In-Reply-To: References: Message-ID: <5d6ba8fc-56df-90aa-f3a4-ac3cf8719e80@stats.ox.ac.uk> On 15/07/2020 09:50, Jeroen Ooms wrote: > On Tue, Jul 14, 2020 at 4:22 PM Prof Brian Ripley wrote: >> >> This is a rather technical post about how libraries of compiled code can >> be further optimized. LTO generally produces smaller[*] and faster code >> (typically by a few percent) at the expense of increased installation >> time and is being used for large projects such as browsers and soon for >> some Linux distributions. >> >> I have committed a series of enhancements to LTO support in R-devel and >> will shortly port the more important of these to R-patched. > > Would it be worthwhile looking into this for Windows? We did enable > support for LTO in the rtools40 toolchains*, but those are gcc-8.3.0 > and some of the benefits require gcc-9. > > * https://github.com/r-windows/rtools-packages/blob/master/mingw-w64-gcc/PKGBUILD#L166 Way off topic for R-sig-mac, but it is under discussion for Windows once all the planned LTO changes are in. A minor point which is relevant here: the recommended gfortran distribution for macOS (which is from GCC 8.2) contains gcc and g++. So Mac users could try that to get C/Fortran consistency checks. However, only much later versions are compatible with Catalina's SDK (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835), and from trying on High Sierra it looks like Apple's linker does not understand GCC's LTO format. -- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford From kry|ov@r00t @end|ng |rom gm@||@com Tue Jul 21 15:00:57 2020 From: kry|ov@r00t @end|ng |rom gm@||@com (Ivan Krylov) Date: Tue, 21 Jul 2020 16:00:57 +0300 Subject: [R-SIG-Mac] [R-pkg-devel] os/x compiled w/ openmp? In-Reply-To: <20200721115727.6kclscyu5vb5figc@cocoa> References: <20200713141414.piydxyjzyslfqg2a-3708@cocoa> <20200721132417.12420599@trisector> <20200721115727.6kclscyu5vb5figc@cocoa> Message-ID: <20200721160057.5b078895@trisector> On Tue, 21 Jul 2020 07:57:27 -0400 Joshua N Pritikin wrote: > Are you aware of any CRAN packages built by Travis with OpenMP > enabled? Actually, I should have linked to (sorry, I was not aware of it when I posted the first one). Downloading (preferably caching) a .dylib and a few headers and exporting a few environment variables in a Travis build is probably doable, but I haven't tried it myself. -- Best regards, Ivan From c@@rd|@g@bor @end|ng |rom gm@||@com Thu Jul 23 15:06:14 2020 From: c@@rd|@g@bor @end|ng |rom gm@||@com (=?UTF-8?B?R8OhYm9yIENzw6FyZGk=?=) Date: Thu, 23 Jul 2020 14:06:14 +0100 Subject: [R-SIG-Mac] Daily builds Message-ID: Hi Simon, I wonder if the tarballs and the installers for 4.0 and 4.1 are missing from https://mac.r-project.org/ on purpose. The logs seem to have recent dates, but the installers or the links to them are not there? Thanks much, Gabor