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

Hugh Parsonage hugh@p@r@on@ge @end|ng |rom gm@||@com
Wed Sep 9 09:30:17 CEST 2020


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.

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.
>
>



More information about the R-devel mailing list