Re: [Rd] R 4.0.2 64-bit Windows hangs
On 8/27/20 8:38 PM, Jeroen Ooms wrote: On Wed, Aug 26, 2020 at 7:54 PM Tomas Kalibera wrote: On 8/25/20 6:14 PM, Tomas Kalibera wrote: On 8/22/20 9:33 PM, Jeroen Ooms wrote: On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera wrote: On 8/22/20 8:26 PM, Tomas Kalibera wrote: On 8/22/20 7:58 PM, Jeroen Ooms wrote: On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera wrote: On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: Ah yes, this is related. I reported v2010 below, but it looks like I was updated to this Insider Build overnight without my knowledge, and conflated it with the new installation R v4 this morning. I will continue to look into the issue with the methods Tomas mentioned. It is interesting that a rare 5 years old problem would re-appear on current Insider builds. Which build of Windows are you running exactly? I've seen another report about a crash on 20190.1000. It'd be nice to know if it is present also in newer builds, i.e. in 20197. I installed the latest 20197 build in a vm, and I can indeed reproduce this problem. What seems to be happening is that R triggers an infinite recursion in Windows unwinding mechanism, and eventually dies with a stack overflow. Attached a backtrace of the initial 100 frames of the main thread (the pattern in the top ~30 frames continues forever). The microsoft blog doesn't mention anything related to exception handling has changed in recent versions: https://docs.microsoft.com/en-us/windows-insider/at-home/active-dev-branch Thanks, unfortunately that does not ring any bells (except below), I can't guess from this what is the underlying cause of the problem. There may be something wrong in how we use setjmp/longjmp or how setjmp/longjmp works on Windows. It reminds me of a problem I've been debugging few days ago, when longjump implementation segfaults on Windows 10 (recent but not Insider build) probably soon after unwinding the stack, but only with GCC 10 / MinGW 7 and only in one of the no-segfault tests, and only with -03 (not -O2, not with with -O3 -fno-split-loops). The problem was sensitive to these optimization options interestingly on the call site of long jump (do_abs), even when it was not an immediate caller of the longjump. I've not tracked this down yet, it will require looking at the assembly level, and I was suspecting a compiler error causing the compiler to generate code that messes with the stack or registers in a way that impacts the upcoming jump. But now as we have this other problem with setjmp/logjmp, the compiler may not be the top suspect anymore. I may not be able to work on this in the next few days or a week, so if anyone gets there first, please let me know what you find out. Btw could you please try out if the UCRT build of R crashes as well in the Insider Windows build ? Yes, it hangs in exactly the same way, except that the backtrace shows ucrtbase!.intrinsic_setjmpex () from C:\WINDOWS\System32\ucrtbase.dll Instead of msvcrt!_setjmpex (as expected of course). Thanks. I found what is causing the problem I observed with GCC10/stock Windows 10, I expect this is the same one as in the Insider build. I will investigate further, Tomas It seems the problem is between MinGW-W64 and Windows, and really it causes both the reported crashes in an Insider build (I tested in 20197) and in my GCC 10 builds in a single "no-segfault" test. setjmp is implemented using Windows call _setjmpex, which has a second argument argument, which is set differently by MinGW based on GCC version. When I set this argument as MinGW-W64 did on early versions of GCC, mingw_getsp(), it fixes/hides the problems on my systems. Perl5 uses a similar workaround, but otherwise there is no solid base (documentation, specification, etc) I am aware of for this change, so this may take some more time to be properly fixed. Still, if anyone experiments with this workaround and finds a problem, please let me know. In particular, I am curious whether it works on earlier versions of Windows (at least with check-all, including recommended packages). FYI, the problem has disappeared on Windows dev built 20201 (released yesterday), so it may have been a Windows bug. That is not to say there is no bug on the R/mingw side, but at least the current and past releases of R are working again on the latest versions of Windows, which is a big relief. I've added a workaround, for now only to R-devel, which fixes both issues: - infinite recursion on startup in 20197 (and some other pre-releases, as reported by others) - segfault during longjump with gcc10 in multiple versions of Windows 10, including 20211 The workaround uses NULL as the second argument to _setjmpex, which effectively disables SEH in internal R code for jump targets created using R's setjmp. This provides the same behavior as we have on Linux, potentially improves performance, and most importantly makes the problem go away. I've tested on CRAN/BIOC packages and did not find
Re: [Rd] R 4.0.2 64-bit Windows hangs
On Wed, Aug 26, 2020 at 7:54 PM Tomas Kalibera wrote: > > On 8/25/20 6:14 PM, Tomas Kalibera wrote: > > On 8/22/20 9:33 PM, Jeroen Ooms wrote: > >> On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera > >> wrote: > >>> On 8/22/20 8:26 PM, Tomas Kalibera wrote: > On 8/22/20 7:58 PM, Jeroen Ooms wrote: > > On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera > > wrote: > >> On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: > >>> Ah yes, this is related. I reported v2010 below, but it looks like > >>> I was updated to this Insider Build overnight without my knowledge, > >>> and conflated it with the new installation R v4 this morning. > >>> > >>> I will continue to look into the issue with the methods Tomas > >>> mentioned. > >> It is interesting that a rare 5 years old problem would re-appear on > >> current Insider builds. Which build of Windows are you running > >> exactly? > >> I've seen another report about a crash on 20190.1000. It'd be > >> nice to > >> know if it is present also in newer builds, i.e. in 20197. > > I installed the latest 20197 build in a vm, and I can indeed > > reproduce > > this problem. > > > > What seems to be happening is that R triggers an infinite > > recursion in > > Windows unwinding mechanism, and eventually dies with a stack > > overflow. Attached a backtrace of the initial 100 frames of the main > > thread (the pattern in the top ~30 frames continues forever). > > > > The microsoft blog doesn't mention anything related to exception > > handling has changed in recent versions: > > https://docs.microsoft.com/en-us/windows-insider/at-home/active-dev-branch > > > > > Thanks, unfortunately that does not ring any bells (except below), I > can't guess from this what is the underlying cause of the problem. > There may be something wrong in how we use setjmp/longjmp or how > setjmp/longjmp works on Windows. > > It reminds me of a problem I've been debugging few days ago, when > longjump implementation segfaults on Windows 10 (recent but not > Insider build) probably soon after unwinding the stack, but only with > GCC 10 / MinGW 7 and only in one of the no-segfault tests, and only > with -03 (not -O2, not with with -O3 -fno-split-loops). The problem > was sensitive to these optimization options interestingly on the call > site of long jump (do_abs), even when it was not an immediate caller > of the longjump. I've not tracked this down yet, it will require > looking at the assembly level, and I was suspecting a compiler error > causing the compiler to generate code that messes with the stack or > registers in a way that impacts the upcoming jump. But now as we have > this other problem with setjmp/logjmp, the compiler may not be the top > suspect anymore. > > I may not be able to work on this in the next few days or a week, so > if anyone gets there first, please let me know what you find out. > >>> Btw could you please try out if the UCRT build of R crashes as well in > >>> the Insider Windows build ? > >> Yes, it hangs in exactly the same way, except that the backtrace shows > >> > >> ucrtbase!.intrinsic_setjmpex () from C:\WINDOWS\System32\ucrtbase.dll > >> > >> Instead of msvcrt!_setjmpex (as expected of course). > > > > Thanks. I found what is causing the problem I observed with > > GCC10/stock Windows 10, I expect this is the same one as in the > > Insider build. > > I will investigate further, > > > > Tomas > > > It seems the problem is between MinGW-W64 and Windows, and really it > causes both the reported crashes in an Insider build (I tested in 20197) > and in my GCC 10 builds in a single "no-segfault" test. setjmp is > implemented using Windows call _setjmpex, which has a second argument > argument, which is set differently by MinGW based on GCC version. When I > set this argument as MinGW-W64 did on early versions of GCC, > mingw_getsp(), it fixes/hides the problems on my systems. Perl5 uses a > similar workaround, but otherwise there is no solid base (documentation, > specification, etc) I am aware of for this change, so this may take some > more time to be properly fixed. Still, if anyone experiments with this > workaround and finds a problem, please let me know. In particular, I am > curious whether it works on earlier versions of Windows (at least with > check-all, including recommended packages). FYI, the problem has disappeared on Windows dev built 20201 (released yesterday), so it may have been a Windows bug. That is not to say there is no bug on the R/mingw side, but at least the current and past releases of R are working again on the latest versions of Windows, which is a big relief. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
On 8/25/20 6:14 PM, Tomas Kalibera wrote: On 8/22/20 9:33 PM, Jeroen Ooms wrote: On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera wrote: On 8/22/20 8:26 PM, Tomas Kalibera wrote: On 8/22/20 7:58 PM, Jeroen Ooms wrote: On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera wrote: On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: Ah yes, this is related. I reported v2010 below, but it looks like I was updated to this Insider Build overnight without my knowledge, and conflated it with the new installation R v4 this morning. I will continue to look into the issue with the methods Tomas mentioned. It is interesting that a rare 5 years old problem would re-appear on current Insider builds. Which build of Windows are you running exactly? I've seen another report about a crash on 20190.1000. It'd be nice to know if it is present also in newer builds, i.e. in 20197. I installed the latest 20197 build in a vm, and I can indeed reproduce this problem. What seems to be happening is that R triggers an infinite recursion in Windows unwinding mechanism, and eventually dies with a stack overflow. Attached a backtrace of the initial 100 frames of the main thread (the pattern in the top ~30 frames continues forever). The microsoft blog doesn't mention anything related to exception handling has changed in recent versions: https://docs.microsoft.com/en-us/windows-insider/at-home/active-dev-branch Thanks, unfortunately that does not ring any bells (except below), I can't guess from this what is the underlying cause of the problem. There may be something wrong in how we use setjmp/longjmp or how setjmp/longjmp works on Windows. It reminds me of a problem I've been debugging few days ago, when longjump implementation segfaults on Windows 10 (recent but not Insider build) probably soon after unwinding the stack, but only with GCC 10 / MinGW 7 and only in one of the no-segfault tests, and only with -03 (not -O2, not with with -O3 -fno-split-loops). The problem was sensitive to these optimization options interestingly on the call site of long jump (do_abs), even when it was not an immediate caller of the longjump. I've not tracked this down yet, it will require looking at the assembly level, and I was suspecting a compiler error causing the compiler to generate code that messes with the stack or registers in a way that impacts the upcoming jump. But now as we have this other problem with setjmp/logjmp, the compiler may not be the top suspect anymore. I may not be able to work on this in the next few days or a week, so if anyone gets there first, please let me know what you find out. Btw could you please try out if the UCRT build of R crashes as well in the Insider Windows build ? Yes, it hangs in exactly the same way, except that the backtrace shows ucrtbase!.intrinsic_setjmpex () from C:\WINDOWS\System32\ucrtbase.dll Instead of msvcrt!_setjmpex (as expected of course). Thanks. I found what is causing the problem I observed with GCC10/stock Windows 10, I expect this is the same one as in the Insider build. I will investigate further, Tomas It seems the problem is between MinGW-W64 and Windows, and really it causes both the reported crashes in an Insider build (I tested in 20197) and in my GCC 10 builds in a single "no-segfault" test. setjmp is implemented using Windows call _setjmpex, which has a second argument argument, which is set differently by MinGW based on GCC version. When I set this argument as MinGW-W64 did on early versions of GCC, mingw_getsp(), it fixes/hides the problems on my systems. Perl5 uses a similar workaround, but otherwise there is no solid base (documentation, specification, etc) I am aware of for this change, so this may take some more time to be properly fixed. Still, if anyone experiments with this workaround and finds a problem, please let me know. In particular, I am curious whether it works on earlier versions of Windows (at least with check-all, including recommended packages). Thanks Tomas Index: src/gnuwin32/fixed/h/psignal.h === --- src/gnuwin32/fixed/h/psignal.h (revision 79084) +++ src/gnuwin32/fixed/h/psignal.h (working copy) @@ -30,6 +30,15 @@ #include #include +#if defined(__MINGW64__) + #undef setjmp + #ifdef _UCRT +#define setjmp(x) __intrinsic_setjmpex((x), mingw_getsp()) + #else +#define setjmp(x) _setjmp((x), mingw_getsp()) + #endif +#endif + #define SIGHUP 1 /* hangup */ #define SIGINT 2 /* interrupt */ #define SIGQUIT 3 /* quit */ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
On 8/22/20 9:33 PM, Jeroen Ooms wrote: On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera wrote: On 8/22/20 8:26 PM, Tomas Kalibera wrote: On 8/22/20 7:58 PM, Jeroen Ooms wrote: On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera wrote: On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: Ah yes, this is related. I reported v2010 below, but it looks like I was updated to this Insider Build overnight without my knowledge, and conflated it with the new installation R v4 this morning. I will continue to look into the issue with the methods Tomas mentioned. It is interesting that a rare 5 years old problem would re-appear on current Insider builds. Which build of Windows are you running exactly? I've seen another report about a crash on 20190.1000. It'd be nice to know if it is present also in newer builds, i.e. in 20197. I installed the latest 20197 build in a vm, and I can indeed reproduce this problem. What seems to be happening is that R triggers an infinite recursion in Windows unwinding mechanism, and eventually dies with a stack overflow. Attached a backtrace of the initial 100 frames of the main thread (the pattern in the top ~30 frames continues forever). The microsoft blog doesn't mention anything related to exception handling has changed in recent versions: https://docs.microsoft.com/en-us/windows-insider/at-home/active-dev-branch Thanks, unfortunately that does not ring any bells (except below), I can't guess from this what is the underlying cause of the problem. There may be something wrong in how we use setjmp/longjmp or how setjmp/longjmp works on Windows. It reminds me of a problem I've been debugging few days ago, when longjump implementation segfaults on Windows 10 (recent but not Insider build) probably soon after unwinding the stack, but only with GCC 10 / MinGW 7 and only in one of the no-segfault tests, and only with -03 (not -O2, not with with -O3 -fno-split-loops). The problem was sensitive to these optimization options interestingly on the call site of long jump (do_abs), even when it was not an immediate caller of the longjump. I've not tracked this down yet, it will require looking at the assembly level, and I was suspecting a compiler error causing the compiler to generate code that messes with the stack or registers in a way that impacts the upcoming jump. But now as we have this other problem with setjmp/logjmp, the compiler may not be the top suspect anymore. I may not be able to work on this in the next few days or a week, so if anyone gets there first, please let me know what you find out. Btw could you please try out if the UCRT build of R crashes as well in the Insider Windows build ? Yes, it hangs in exactly the same way, except that the backtrace shows ucrtbase!.intrinsic_setjmpex () from C:\WINDOWS\System32\ucrtbase.dll Instead of msvcrt!_setjmpex (as expected of course). Thanks. I found what is causing the problem I observed with GCC10/stock Windows 10, I expect this is the same one as in the Insider build. I will investigate further, Tomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera wrote: > > On 8/22/20 8:26 PM, Tomas Kalibera wrote: > > On 8/22/20 7:58 PM, Jeroen Ooms wrote: > >> On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera > >> wrote: > >>> On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: > Ah yes, this is related. I reported v2010 below, but it looks like > I was updated to this Insider Build overnight without my knowledge, > and conflated it with the new installation R v4 this morning. > > I will continue to look into the issue with the methods Tomas > mentioned. > >>> It is interesting that a rare 5 years old problem would re-appear on > >>> current Insider builds. Which build of Windows are you running exactly? > >>> I've seen another report about a crash on 20190.1000. It'd be nice to > >>> know if it is present also in newer builds, i.e. in 20197. > >> I installed the latest 20197 build in a vm, and I can indeed reproduce > >> this problem. > >> > >> What seems to be happening is that R triggers an infinite recursion in > >> Windows unwinding mechanism, and eventually dies with a stack > >> overflow. Attached a backtrace of the initial 100 frames of the main > >> thread (the pattern in the top ~30 frames continues forever). > >> > >> The microsoft blog doesn't mention anything related to exception > >> handling has changed in recent versions: > >> https://docs.microsoft.com/en-us/windows-insider/at-home/active-dev-branch > >> > > > > Thanks, unfortunately that does not ring any bells (except below), I > > can't guess from this what is the underlying cause of the problem. > > There may be something wrong in how we use setjmp/longjmp or how > > setjmp/longjmp works on Windows. > > > > It reminds me of a problem I've been debugging few days ago, when > > longjump implementation segfaults on Windows 10 (recent but not > > Insider build) probably soon after unwinding the stack, but only with > > GCC 10 / MinGW 7 and only in one of the no-segfault tests, and only > > with -03 (not -O2, not with with -O3 -fno-split-loops). The problem > > was sensitive to these optimization options interestingly on the call > > site of long jump (do_abs), even when it was not an immediate caller > > of the longjump. I've not tracked this down yet, it will require > > looking at the assembly level, and I was suspecting a compiler error > > causing the compiler to generate code that messes with the stack or > > registers in a way that impacts the upcoming jump. But now as we have > > this other problem with setjmp/logjmp, the compiler may not be the top > > suspect anymore. > > > > I may not be able to work on this in the next few days or a week, so > > if anyone gets there first, please let me know what you find out. > > Btw could you please try out if the UCRT build of R crashes as well in > the Insider Windows build ? Yes, it hangs in exactly the same way, except that the backtrace shows ucrtbase!.intrinsic_setjmpex () from C:\WINDOWS\System32\ucrtbase.dll Instead of msvcrt!_setjmpex (as expected of course). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
On 8/22/20 8:26 PM, Tomas Kalibera wrote: On 8/22/20 7:58 PM, Jeroen Ooms wrote: On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera wrote: On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: Ah yes, this is related. I reported v2010 below, but it looks like I was updated to this Insider Build overnight without my knowledge, and conflated it with the new installation R v4 this morning. I will continue to look into the issue with the methods Tomas mentioned. It is interesting that a rare 5 years old problem would re-appear on current Insider builds. Which build of Windows are you running exactly? I've seen another report about a crash on 20190.1000. It'd be nice to know if it is present also in newer builds, i.e. in 20197. I installed the latest 20197 build in a vm, and I can indeed reproduce this problem. What seems to be happening is that R triggers an infinite recursion in Windows unwinding mechanism, and eventually dies with a stack overflow. Attached a backtrace of the initial 100 frames of the main thread (the pattern in the top ~30 frames continues forever). The microsoft blog doesn't mention anything related to exception handling has changed in recent versions: https://docs.microsoft.com/en-us/windows-insider/at-home/active-dev-branch Thanks, unfortunately that does not ring any bells (except below), I can't guess from this what is the underlying cause of the problem. There may be something wrong in how we use setjmp/longjmp or how setjmp/longjmp works on Windows. It reminds me of a problem I've been debugging few days ago, when longjump implementation segfaults on Windows 10 (recent but not Insider build) probably soon after unwinding the stack, but only with GCC 10 / MinGW 7 and only in one of the no-segfault tests, and only with -03 (not -O2, not with with -O3 -fno-split-loops). The problem was sensitive to these optimization options interestingly on the call site of long jump (do_abs), even when it was not an immediate caller of the longjump. I've not tracked this down yet, it will require looking at the assembly level, and I was suspecting a compiler error causing the compiler to generate code that messes with the stack or registers in a way that impacts the upcoming jump. But now as we have this other problem with setjmp/logjmp, the compiler may not be the top suspect anymore. I may not be able to work on this in the next few days or a week, so if anyone gets there first, please let me know what you find out. Btw could you please try out if the UCRT build of R crashes as well in the Insider Windows build ? https://www.r-project.org/nosvn/winutf8/R-devel-win.exe Thanks Tomas (from https://developer.r-project.org/Blog/public/2020/07/30/windows/utf-8-build-of-r-and-cran-packages) Thanks, Tomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera wrote: > > On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: > > Ah yes, this is related. I reported v2010 below, but it looks like I was > > updated to this Insider Build overnight without my knowledge, and conflated > > it with the new installation R v4 this morning. > > > > I will continue to look into the issue with the methods Tomas mentioned. > > It is interesting that a rare 5 years old problem would re-appear on > current Insider builds. Which build of Windows are you running exactly? > I've seen another report about a crash on 20190.1000. It'd be nice to > know if it is present also in newer builds, i.e. in 20197. I installed the latest 20197 build in a vm, and I can indeed reproduce this problem. What seems to be happening is that R triggers an infinite recursion in Windows unwinding mechanism, and eventually dies with a stack overflow. Attached a backtrace of the initial 100 frames of the main thread (the pattern in the top ~30 frames continues forever). The microsoft blog doesn't mention anything related to exception handling has changed in recent versions: https://docs.microsoft.com/en-us/windows-insider/at-home/active-dev-branch #39431 0x7ffe105a8d77 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39432 0x7ffe105a8b07 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39433 0x7ffe105a7258 in ntdll!RtlInitializeExtendedContext () from C:\WINDOWS\SYSTEM32\ntdll.dll #39434 0x7ffe10639d5e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll #39435 0x7ffe105a9584 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39436 0x7ffe105a8d77 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39437 0x7ffe105a8b07 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39438 0x7ffe105a7258 in ntdll!RtlInitializeExtendedContext () from C:\WINDOWS\SYSTEM32\ntdll.dll #39439 0x7ffe10639d5e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll #39440 0x7ffe105a9584 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39441 0x7ffe105a8d77 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39442 0x7ffe105a8b07 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39443 0x7ffe105a7258 in ntdll!RtlInitializeExtendedContext () from C:\WINDOWS\SYSTEM32\ntdll.dll #39444 0x7ffe10639d5e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll #39445 0x7ffe105a9584 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39446 0x7ffe105a8d77 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39447 0x7ffe105a8b07 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39448 0x7ffe105a7258 in ntdll!RtlInitializeExtendedContext () from C:\WINDOWS\SYSTEM32\ntdll.dll #39449 0x7ffe10639d5e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll #39450 0x7ffe105a9584 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39451 0x7ffe105a8d77 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39452 0x7ffe105a8b07 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39453 0x7ffe105a7258 in ntdll!RtlInitializeExtendedContext () from C:\WINDOWS\SYSTEM32\ntdll.dll #39454 0x7ffe10639d5e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll #39455 0x7ffe105a9584 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39456 0x7ffe105a8d77 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39457 0x7ffe105a8b07 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39458 0x7ffe105a7258 in ntdll!RtlInitializeExtendedContext () from C:\WINDOWS\SYSTEM32\ntdll.dll #39459 0x7ffe10639d5e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll #39460 0x7ffe105a9584 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39461 0x7ffe105a8d77 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39462 0x7ffe105a8b07 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39463 0x7ffe105a7258 in ntdll!RtlInitializeExtendedContext () from C:\WINDOWS\SYSTEM32\ntdll.dll #39464 0x7ffe10639d5e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll #39465 0x7ffe105a9584 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39466 0x7ffe105a8d77 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39467 0x7ffe105a8b07 in ntdll!RtlVirtualUnwind () from C:\WINDOWS\SYSTEM32\ntdll.dll #39468 0x7ffe105a7258 in ntdll!RtlInitializeExtendedContext () from C:\WINDOWS\SYSTEM32\ntdll.dll #39469 0x7ffe10639d5e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll #39470 0x7ffe105a9584 in ntdll!RtlVirtualUnwind ()
Re: [Rd] R 4.0.2 64-bit Windows hangs
On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: Ah yes, this is related. I reported v2010 below, but it looks like I was updated to this Insider Build overnight without my knowledge, and conflated it with the new installation R v4 this morning. I will continue to look into the issue with the methods Tomas mentioned. It is interesting that a rare 5 years old problem would re-appear on current Insider builds. Which build of Windows are you running exactly? I've seen another report about a crash on 20190.1000. It'd be nice to know if it is present also in newer builds, i.e. in 20197. Thanks Tomas Many thanks. On 2020-08-21 21:05:51 nos...@altfeld-im.de wrote: May be unrelated but on SO there is a report that a Windows update may cause this problem: https://stackoverflow.com/questions/63457321/r-will-not-run-after-latest-windows-10-updates/63524608#63524608 On Fri, 2020-08-21 at 12:34 +, m1388m+moe1ydyn0hbs--- via R-devel wrote: I am having exactly the same issue as the following bug report: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515. RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit RTerm.exe runs fine. No errors are displayed, but I see the same as the bug report in Event Viewer. I am running Windows 10 64-bit, v2010. Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
Ah yes, this is related. I reported v2010 below, but it looks like I was updated to this Insider Build overnight without my knowledge, and conflated it with the new installation R v4 this morning. I will continue to look into the issue with the methods Tomas mentioned. Many thanks. On 2020-08-21 21:05:51 nos...@altfeld-im.de wrote: > May be unrelated but on SO there is a report that a Windows update may > cause this problem: > > https://stackoverflow.com/questions/63457321/r-will-not-run-after-latest-windows-10-updates/63524608#63524608 > > > > On Fri, 2020-08-21 at 12:34 +, m1388m+moe1ydyn0hbs--- via R-devel > wrote: > > I am having exactly the same issue as the following bug report: > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515. > > > > RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit > RTerm.exe runs fine. > > > > No errors are displayed, but I see the same as the bug report in Event > Viewer. > > > > I am running Windows 10 64-bit, v2010. > > > > > > > > > > > > > > Sent using Guerrillamail.com > > Block or report abuse: > https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX > > > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
May be unrelated but on SO there is a report that a Windows update may cause this problem: https://stackoverflow.com/questions/63457321/r-will-not-run-after-latest-windows-10-updates/63524608#63524608 On Fri, 2020-08-21 at 12:34 +, m1388m+moe1ydyn0hbs--- via R-devel wrote: > I am having exactly the same issue as the following bug report: > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515. > > RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit > RTerm.exe runs fine. > > No errors are displayed, but I see the same as the bug report in Event Viewer. > > I am running Windows 10 64-bit, v2010. > > > > > > > Sent using Guerrillamail.com > Block or report abuse: > https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
On 8/21/20 9:20 PM, m17hpj+bt626qpx8w70w--- via R-devel wrote: For some further information, on compiling with rtools, using the following scripts, https://github.com/r-windows/r-base, I receive a segfault: installing 'sysdata.rda' building package 'compiler' byte-compiling package 'compiler' byte-compiling package 'base' byte-compiling package 'tools' sh: line 3: 3614 Done( cat ./R/makeLazyLoad.R; echo "makeLazyLoading(\"tools\")" ) 3615 Segmentation fault | _R_COMPILE_PKGS_=1 R_COMPILER_SUPPRESS_ALL=1 R_DEFAULT_PACKAGES=NULL LC_ALL=C R_ENABLE_JIT=0 ../../../bin/x64/Rterm.exe --vanilla --no-echo > /dev/null make[2]: *** [Makefile.win:34: ../../../library/tools/R/tools.rdb] Error 139 make[1]: *** [Makefile.win:33: R] Error 1 make: *** [Makefile:18: all] Error 2 It looks to have compiled its own Rterm.exe, and segfaults when running it? You can try building with debug symbols, for simplicity even disabling optimization, and then running RTerm in a debugger and see where it is crashing. Maybe it is related to the problem you are seeing in the installed version of R. Or, better from the other end, you could try to experiment with your system to find out which configuration may be impacting the problem. R is not doing anything special/custom linking to the system DLLs. You can check your PATH settings, make sure you run from cmd.exe (not Visual Studio, etc). You can start playing with the registry keys. Maybe there is some leftover from the Microsoft distribution of R (they have their own installer). Maybe there was some manual modification of registry keys by some external software, etc. You can read the sources to see which keys normally get set (src/gnuwin32/installer/*), or you can install into a fresh VM from the CRAN installer and check there. Windows allow to set debugging flags on the dynamic loader (per binary - without recompilation), perhaps that might help too to identify why the wrong library is loaded (even though that tends to be verbose). It would be useful to know why it is happening, as you are not the first one who ran into a similar problem (the reporter of the bug did as well), but you are probably the only one who can find out. Tomas On 2020-08-21 18:48:42 murdoch.dun...@gmail.com wrote: On 21/08/2020 12:53 p.m., m15g9g+1dq20lw4vyh1s--- via R-devel wrote: Thanks for the response. Having spent a lot of the day trying to solve this, as R is essential for my workflow, I've tried to debug via the binary only as I haven't yet got the toolchain working - I'm quite inexperienced at this. I've confirmed the problem is exactly as described in the initial (albeit old) bug report. The exception that's thrown within Visual Studio is: "Exception thrown at 0x7FFBF1E3C0C8 (ntdll.dll) in Rterm.exe: 0xC005: Access violation reading location 0x." As the problem appears to be persistent and cross many versions of Windows, could it hint towards this being a problem within R's codebase rather than my specific setup? I understand that this is hard to reproduce, however, and I'll doing my best at trying to compile/debug from source if there are no obvious answers. On 2020-08-21 15:59:49 tomas.kalib...@gmail.com wrote: On 8/21/20 2:34 PM, m1388m+moe1ydyn0hbs--- via R-devel wrote: I am having exactly the same issue as the following bug report: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515. RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit RTerm.exe runs fine. No errors are displayed, but I see the same as the bug report in Event Viewer. I am running Windows 10 64-bit, v2010. Thanks for the report, but please try to provide more information and diagnose a bit of the problem on your own - this is a very rare problem, many people use R on Windows 10, the 64-bit version. There must be something special about your installation, your operating system, etc and unless someone finds out what it is, the issue can't be fixed. You will see that if you install a clean version of stock Windows 10 in a virtual machine and install R 4.0.2 or R-devel from the CRAN installer, it will work. PR16515 was for a much older version of R, for a different version of Windows, with detailed info of what was happening. Still, without any clue why, and as nobody who could find out why could reproduce, it is still open. Thanks Tomas Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
I'm only using Visual Studio to debug. I'm using R version 4.0.2 from: https://cran.r-project.org/, and have tested the patched version. Even the x64 version of the previous version of R (3.6) does not run. I have previously had Microsoft R Open installed on the machine, but it's been uninstalled. Thanks. On 2020-08-21 18:48:42 murdoch.dun...@gmail.com wrote: > Are you normally running from Visual Studio, or only when trying to > debug? Where did you download R from, and which version? The bug > report mentions Registry key > > HKCU\Software\Microsoft\InteliPoint\AppSpecific\Rgui.exe > > which I believe is installed by the Microsoft R Client rather than the > CRAN distribution of R. > > Duncan Murdoch > > On 21/08/2020 12:53 p.m., m15g9g+1dq20lw4vyh1s--- via R-devel wrote: > > Thanks for the response. Having spent a lot of the day trying to solve > this, as R is essential for my workflow, I've tried to debug via the binary > only as I haven't yet got the toolchain working - I'm quite inexperienced > at this. > > > > I've confirmed the problem is exactly as described in the initial (albeit > old) bug report. The exception that's thrown within Visual Studio is: > > > > "Exception thrown at 0x7FFBF1E3C0C8 (ntdll.dll) in Rterm.exe: > 0xC005: Access violation reading location 0x." > > > > As the problem appears to be persistent and cross many versions of > Windows, could it hint towards this being a problem within R's codebase > rather than my specific setup? > > > > I understand that this is hard to reproduce, however, and I'll doing my > best at trying to compile/debug from source if there are no obvious > answers. > > > > > > On 2020-08-21 15:59:49 tomas.kalib...@gmail.com wrote: > >> On 8/21/20 2:34 PM, m1388m+moe1ydyn0hbs--- via R-devel wrote: > >>> I am having exactly the same issue as the following bug report: > >> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515. > >>> > >>> RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit > >> RTerm.exe runs fine. > >>> > >>> No errors are displayed, but I see the same as the bug report in Event > >> Viewer. > >>> > >>> I am running Windows 10 64-bit, v2010. > >> > >> Thanks for the report, but please try to provide more information and > >> diagnose a bit of the problem on your own - this is a very rare problem, > >> many people use R on Windows 10, the 64-bit version. There must be > >> something special about your installation, your operating system, etc > >> and unless someone finds out what it is, the issue can't be fixed. You > >> will see that if you install a clean version of stock Windows 10 in a > >> virtual machine and install R 4.0.2 or R-devel from the CRAN installer, > >> it will work. > >> > >> PR16515 was for a much older version of R, for a different version of > >> Windows, with detailed info of what was happening. Still, without any > >> clue why, and as nobody who could find out why could reproduce, it is > >> still open. > >> > >> Thanks > >> Tomas > >> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Sent using Guerrillamail.com > >>> Block or report abuse: > >> https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX > >>> > >>> > >>> __ > >>> R-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > > > > > Sent using Guerrillamail.com > > Block or report abuse: > https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX > > > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
For some further information, on compiling with rtools, using the following scripts, https://github.com/r-windows/r-base, I receive a segfault: installing 'sysdata.rda' building package 'compiler' byte-compiling package 'compiler' byte-compiling package 'base' byte-compiling package 'tools' sh: line 3: 3614 Done( cat ./R/makeLazyLoad.R; echo "makeLazyLoading(\"tools\")" ) 3615 Segmentation fault | _R_COMPILE_PKGS_=1 R_COMPILER_SUPPRESS_ALL=1 R_DEFAULT_PACKAGES=NULL LC_ALL=C R_ENABLE_JIT=0 ../../../bin/x64/Rterm.exe --vanilla --no-echo > /dev/null make[2]: *** [Makefile.win:34: ../../../library/tools/R/tools.rdb] Error 139 make[1]: *** [Makefile.win:33: R] Error 1 make: *** [Makefile:18: all] Error 2 It looks to have compiled its own Rterm.exe, and segfaults when running it? On 2020-08-21 18:48:42 murdoch.dun...@gmail.com wrote: > > On 21/08/2020 12:53 p.m., m15g9g+1dq20lw4vyh1s--- via R-devel wrote: > > Thanks for the response. Having spent a lot of the day trying to solve > this, as R is essential for my workflow, I've tried to debug via the binary > only as I haven't yet got the toolchain working - I'm quite inexperienced > at this. > > > > I've confirmed the problem is exactly as described in the initial (albeit > old) bug report. The exception that's thrown within Visual Studio is: > > > > "Exception thrown at 0x7FFBF1E3C0C8 (ntdll.dll) in Rterm.exe: > 0xC005: Access violation reading location 0x." > > > > As the problem appears to be persistent and cross many versions of > Windows, could it hint towards this being a problem within R's codebase > rather than my specific setup? > > > > I understand that this is hard to reproduce, however, and I'll doing my > best at trying to compile/debug from source if there are no obvious > answers. > > > > > > On 2020-08-21 15:59:49 tomas.kalib...@gmail.com wrote: > >> On 8/21/20 2:34 PM, m1388m+moe1ydyn0hbs--- via R-devel wrote: > >>> I am having exactly the same issue as the following bug report: > >> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515. > >>> > >>> RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit > >> RTerm.exe runs fine. > >>> > >>> No errors are displayed, but I see the same as the bug report in Event > >> Viewer. > >>> > >>> I am running Windows 10 64-bit, v2010. > >> > >> Thanks for the report, but please try to provide more information and > >> diagnose a bit of the problem on your own - this is a very rare problem, > >> many people use R on Windows 10, the 64-bit version. There must be > >> something special about your installation, your operating system, etc > >> and unless someone finds out what it is, the issue can't be fixed. You > >> will see that if you install a clean version of stock Windows 10 in a > >> virtual machine and install R 4.0.2 or R-devel from the CRAN installer, > >> it will work. > >> > >> PR16515 was for a much older version of R, for a different version of > >> Windows, with detailed info of what was happening. Still, without any > >> clue why, and as nobody who could find out why could reproduce, it is > >> still open. > >> > >> Thanks > >> Tomas > >> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Sent using Guerrillamail.com > >>> Block or report abuse: > >> https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX > >>> > >>> > >>> __ > >>> R-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > > > > > Sent using Guerrillamail.com > > Block or report abuse: > https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX > > > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
Are you normally running from Visual Studio, or only when trying to debug? Where did you download R from, and which version? The bug report mentions Registry key HKCU\Software\Microsoft\InteliPoint\AppSpecific\Rgui.exe which I believe is installed by the Microsoft R Client rather than the CRAN distribution of R. Duncan Murdoch On 21/08/2020 12:53 p.m., m15g9g+1dq20lw4vyh1s--- via R-devel wrote: Thanks for the response. Having spent a lot of the day trying to solve this, as R is essential for my workflow, I've tried to debug via the binary only as I haven't yet got the toolchain working - I'm quite inexperienced at this. I've confirmed the problem is exactly as described in the initial (albeit old) bug report. The exception that's thrown within Visual Studio is: "Exception thrown at 0x7FFBF1E3C0C8 (ntdll.dll) in Rterm.exe: 0xC005: Access violation reading location 0x." As the problem appears to be persistent and cross many versions of Windows, could it hint towards this being a problem within R's codebase rather than my specific setup? I understand that this is hard to reproduce, however, and I'll doing my best at trying to compile/debug from source if there are no obvious answers. On 2020-08-21 15:59:49 tomas.kalib...@gmail.com wrote: On 8/21/20 2:34 PM, m1388m+moe1ydyn0hbs--- via R-devel wrote: I am having exactly the same issue as the following bug report: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515. RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit RTerm.exe runs fine. No errors are displayed, but I see the same as the bug report in Event Viewer. I am running Windows 10 64-bit, v2010. Thanks for the report, but please try to provide more information and diagnose a bit of the problem on your own - this is a very rare problem, many people use R on Windows 10, the 64-bit version. There must be something special about your installation, your operating system, etc and unless someone finds out what it is, the issue can't be fixed. You will see that if you install a clean version of stock Windows 10 in a virtual machine and install R 4.0.2 or R-devel from the CRAN installer, it will work. PR16515 was for a much older version of R, for a different version of Windows, with detailed info of what was happening. Still, without any clue why, and as nobody who could find out why could reproduce, it is still open. Thanks Tomas Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
Thanks for the response. Having spent a lot of the day trying to solve this, as R is essential for my workflow, I've tried to debug via the binary only as I haven't yet got the toolchain working - I'm quite inexperienced at this. I've confirmed the problem is exactly as described in the initial (albeit old) bug report. The exception that's thrown within Visual Studio is: "Exception thrown at 0x7FFBF1E3C0C8 (ntdll.dll) in Rterm.exe: 0xC005: Access violation reading location 0x." As the problem appears to be persistent and cross many versions of Windows, could it hint towards this being a problem within R's codebase rather than my specific setup? I understand that this is hard to reproduce, however, and I'll doing my best at trying to compile/debug from source if there are no obvious answers. On 2020-08-21 15:59:49 tomas.kalib...@gmail.com wrote: > On 8/21/20 2:34 PM, m1388m+moe1ydyn0hbs--- via R-devel wrote: > > I am having exactly the same issue as the following bug report: > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515. > > > > RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit > RTerm.exe runs fine. > > > > No errors are displayed, but I see the same as the bug report in Event > Viewer. > > > > I am running Windows 10 64-bit, v2010. > > Thanks for the report, but please try to provide more information and > diagnose a bit of the problem on your own - this is a very rare problem, > many people use R on Windows 10, the 64-bit version. There must be > something special about your installation, your operating system, etc > and unless someone finds out what it is, the issue can't be fixed. You > will see that if you install a clean version of stock Windows 10 in a > virtual machine and install R 4.0.2 or R-devel from the CRAN installer, > it will work. > > PR16515 was for a much older version of R, for a different version of > Windows, with detailed info of what was happening. Still, without any > clue why, and as nobody who could find out why could reproduce, it is > still open. > > Thanks > Tomas > > > > > > > > > > > > > > > Sent using Guerrillamail.com > > Block or report abuse: > https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX > > > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.2 64-bit Windows hangs
On 8/21/20 2:34 PM, m1388m+moe1ydyn0hbs--- via R-devel wrote: I am having exactly the same issue as the following bug report: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515. RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit RTerm.exe runs fine. No errors are displayed, but I see the same as the bug report in Event Viewer. I am running Windows 10 64-bit, v2010. Thanks for the report, but please try to provide more information and diagnose a bit of the problem on your own - this is a very rare problem, many people use R on Windows 10, the 64-bit version. There must be something special about your installation, your operating system, etc and unless someone finds out what it is, the issue can't be fixed. You will see that if you install a clean version of stock Windows 10 in a virtual machine and install R 4.0.2 or R-devel from the CRAN installer, it will work. PR16515 was for a much older version of R, for a different version of Windows, with detailed info of what was happening. Still, without any clue why, and as nobody who could find out why could reproduce, it is still open. Thanks Tomas Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.0.2 64-bit Windows hangs
I am having exactly the same issue as the following bug report: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515. RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit RTerm.exe runs fine. No errors are displayed, but I see the same as the bug report in Event Viewer. I am running Windows 10 64-bit, v2010. Sent using Guerrillamail.com Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
