R 4.0.2 64-bit Windows hangs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

R 4.0.2 64-bit Windows hangs

R devel mailing list
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


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Tomas Kalibera
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
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

R devel mailing list
In reply to this post by R devel mailing list
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 0x00007FFBF1E3C0C8 (ntdll.dll) in Rterm.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF."

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 [hidden email] 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
> >
> >
> > ______________________________________________
> > [hidden email] 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


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Duncan Murdoch-2
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 0x00007FFBF1E3C0C8 (ntdll.dll) in Rterm.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF."
>
> 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 [hidden email] 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
>>>
>>>
>>> ______________________________________________
>>> [hidden email] 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
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

R devel mailing list
In reply to this post by R devel mailing list
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 [hidden email] 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 0x00007FFBF1E3C0C8 (ntdll.dll) in Rterm.exe:
> 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF."
> >
> > 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 [hidden email] 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
> >>>
> >>>
> >>> ______________________________________________
> >>> [hidden email] 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
> >
> >
> > ______________________________________________
> > [hidden email] 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


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

R devel mailing list
In reply to this post by R devel mailing list
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 [hidden email] 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 0x00007FFBF1E3C0C8 (ntdll.dll) in Rterm.exe:
> 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF."
> >
> > 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 [hidden email] 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
> >>>
> >>>
> >>> ______________________________________________
> >>> [hidden email] 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
> >
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> ______________________________________________
> [hidden email] 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


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Tomas Kalibera
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 [hidden email] 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 0x00007FFBF1E3C0C8 (ntdll.dll) in Rterm.exe:
>> 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF."
>>> 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 [hidden email] 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
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] 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
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>> ______________________________________________
>> [hidden email] 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
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

nospam@altfeld-im.de
In reply to this post by R devel mailing list
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 +0000, 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
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

R devel mailing list
In reply to this post by R devel mailing list
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 [hidden email] 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 +0000, 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
> >
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] 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


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Tomas Kalibera
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 [hidden email] 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 +0000, 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
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> ______________________________________________
>> [hidden email] 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
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Jeroen Ooms-2
On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

gdb.txt (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Tomas Kalibera
On 8/22/20 7:58 PM, Jeroen Ooms wrote:

> On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera <[hidden email]> 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.

Thanks,
Tomas

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Tomas Kalibera
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
>> <[hidden email]> 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
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Jeroen Ooms-2
On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera <[hidden email]> 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
> >> <[hidden email]> 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).

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Tomas Kalibera
On 8/22/20 9:33 PM, Jeroen Ooms wrote:

> On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera <[hidden email]> 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
>>>> <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Tomas Kalibera
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
>> <[hidden email]> 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
>>>>> <[hidden email]> 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





______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

setjmp.diff (590 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Jeroen Ooms-2
On Wed, Aug 26, 2020 at 7:54 PM Tomas Kalibera <[hidden email]> 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
> >> <[hidden email]> 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
> >>>>> <[hidden email]> 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.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.2 64-bit Windows hangs

Tomas Kalibera
On 8/27/20 8:38 PM, Jeroen Ooms wrote:

> On Wed, Aug 26, 2020 at 7:54 PM Tomas Kalibera <[hidden email]> 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
>>>> <[hidden email]> 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
>>>>>>> <[hidden email]> 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 any issues,
but potentially this could uncover bugs related to improper use of C++
with R (relying on that C++ destructors are run on R errors/long jumps).
Such bugs should, however, have already been found on Linux where
destructors were never run on long jumps.

Tomas

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel