[Rd] [External] Re: Operations with long altrep vectors cause segfaults on Windows

[Tomas Kalibera]

On 9/9/20 9:30 AM, Hugh Parsonage wrote:
> Thank you!
>
> I get
>
> Starting program: C:\R\R-devel-20200909\bin\x64\Rgui.exe
> [New Thread 19940.0x638c]
> [New Thread 19940.0x102c]
> [New Thread 19940.0x329c]
> [New Thread 19940.0x37dc]
> warning: Invalid parameter passed to C runtime function.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000006c72d206 in compact_intseq_Dataptr (x=0x12783350,
> writeable=<optimized out>) at altclasses.c:169
> 169     altclasses.c: No such file or directory.

Thanks, would you know which svn version this is?

Tomas

>
> On Wed, 9 Sep 2020 at 17:03, Tomas Kalibera <tomas.kalibera using gmail.com> wrote:
>> On 9/9/20 8:48 AM, Hugh Parsonage wrote:
>>> I am unable to set break or use gdb with any success when I use that version.
>>>
>>> On linux I would do R -d gdb but this gives "unknown option '-d' "
>>> while gdb R.exe (in the same directory as the debug version) gives the
>>> same output as before.
>>>
>>> I'm happy to help but I appreciate this list might not be the best
>>> place to get a tutorial on using gdb on Windows.
>> Essentially, the steps are: build with DEBUG=T (to have debug symbols),
>> possibly updating EOPTS in MkRules.local to disable optimizations, then
>> run gdb loading RGui, "set solib-search-path", run RGui from gdb. Then
>> you can break to debugger from RGui menu, or just run the code that
>> segfaults, and you get to gdb and can print the stacktrace, etc. You can
>> find some information in rw-FAQ (R for Windows FAQ), but yes, it is
>> harder than on Linux. We can take care of this report, but of course in
>> the longer term it would help if more people could take their time to
>> setup debugging and analyze bugs even on Windows.
>>
>> Tomas
>>
>>> On Wed, 9 Sep 2020 at 07:47, Jeroen Ooms <jeroenooms using gmail.com> wrote:
>>>> On Tue, Sep 8, 2020 at 11:44 PM Jeroen Ooms <jeroenooms using gmail.com> wrote:
>>>>> On Tue, Sep 8, 2020 at 5:20 PM Tomas Kalibera <tomas.kalibera using gmail.com> wrote:
>>>>>> On 9/8/20 4:48 PM, Hugh Parsonage wrote:
>>>>>>> Unfortunately I only get
>>>>>>>
>>>>>>> [Thread 21752.0x4aa8 exited with code 3221225477]
>>>>>>> [Thread 21752.0x4514 exited with code 3221225477]
>>>>>>> [Thread 21752.0x3f10 exited with code 3221225477]
>>>>>>> [Inferior 1 (process 21752) exited with code 030000000005]
>>>>>>>
>>>>>>> (I'm guessing I would need to build an instrumented version of R, or
>>>>>>> can R be debugged using gdb with an off-the-shelf installation?)
>>>>>> No, the default build lacks debug symbols. You need a build with debug
>>>>>> symbols, and if you can reproduce in a build without compiler
>>>>>> optimizations (-O0), the backtrace may be easier to interpret. Some bugs
>>>>>> however "disappear" when optimizations are disabled. You can build R
>>>>>> from source (and there may be debug builds provided by someone else
>>>>>> (Jeroen?)).
>>>>> Debug builds for each revision are available from
>>>>> https://r-devel.github.io . To download the installer you need to
>>>>> click the github icon in the last column in the table. You need to be
>>>>> signed in with a (free) Github account in order to download builds
>>>>> (artifacts) from Github actions. It will show download links for both
>>>>> the regular installer and installer with debug symbols.
>>>>>
>>>>> In other news, the https://r-devel.github.io table also shows that the
>>>>> fix that martin committed is segfaulting on 32-bit.
>>>> Sorry that was inaccurate, it is not segfaulting at all, but the unit
>>>> test is raising an error on 32-bit.
>>