Problem installing gdb into Rtools42

3 messages · Dominick Samperi, Dirk Eddelbuettel, Tomas Kalibera

Original

1

3

Dominick Samperi

Wed, Jan 18, 2023 7:44 PM #

On second thought, there is a lot of metapramming code in Rcpp that runs
before main, so
I was wrong to say nothing can happen before main() is called.
Strategically placed print
statements may be the best strategy.

On Wed, Jan 18, 2023 at 8:17 PM Dominick Samperi <djsamperi at gmail.com>
wrote:

Since these ?stray threads? were appearing before I installed gdb into
Rtools42, this may be an operating system bug, and not a problem with gdb
or RInside!

Sent from my iPhone

On Jan 18, 2023, at 6:08 PM, Dominick Samperi <djsamperi at gmail.com> wrote:

?
There may be a more serious problem with gdb, or perhaps a very subtle
problem in the RInside package repl function that only appears under
Windows (I reported this in the Rcpp-devel list, where I provided
a small example repl.cpp with Makefile for Windows).

Gdb is invoked as 'gdb repl.exe', a breakpoint is set on main, and the gdb
run
command is entered. Gdb should simply stop at main and wait for the next
command. But instead the program seems to be run, its GUI pops up, and
after a few seconds it terminates and Gdb finally hits main, waiting for
the next command!

This strange behavior does not happen under Linux where the
program runs normally, gdb starts only one thread (see below),
and gdb behaves as you would expect it to.

Normally gdb starts about four threads under Windows, one for the program
to be debugged, and three worker threads. Under Linux/Ubuntu this doesn't
happen, only one thread is created. I'm not sure what the worker threads
are used for.

What seems to be happening here is a stray thread is created for the
program,
one for which the breakpoint doesn't apply, and this thread runs before the
main thread running the desired instance of the program hits the
breakpoint.

At this point the instance of the program running in the main program is
doomed because you cannot start an embedded instance of R more
than once in the same compilation unit, and the stray thread already
started one.

There does seem to be a subtle issue in the repl program under Windows
that is not related to gdb, but this doesn't explain why gdb creates that
stray
thread, making it impossible to proceed with the debugging. Nothing
should happen before gdb hits main, even if there is a bug in repl.

It is possible that static constructors need to be run before main,
but this wouldn't result in the main program block being executed.

Dominick

On Wed, Jan 18, 2023 at 2:10 PM Tomas Kalibera <tomas.kalibera at gmail.com>
wrote:

On 1/18/23 19:41, Dominick Samperi wrote:

Thanks for the detailed feedback Tomas,

I ran the command 'pacman -Syuu' again, just to be sure, and this time it
says "there is nothing to do."

It appears that gdb is working. I was spooked by the diagnostics that you
say is a known (not serious) issue.

My mistake was not setting a breakpoint on main, so I confused problems
with gdb with problems with the program I'm trying to debug!

I am glad it works now for you. Please don't forget to include debug info
(for R or packages, depending on what you need to debug).


Incidentally, my remark about mingw-w64 problems in other communities
alluded to the Haskell development
community, where an ABI incompatibility was discovered about a year ago.
It is discussed by Ben Gamari here
https://gitlab.haskell.org/ghc/ghc/-/issues/19945.

From a quick look it seems to be an incompatibility between two libraries
implementing POSIX regular expressions, essentially a name clash, they just
need to make sure to consistently use one of them. It is not a problem of
MinGW-W64.

Tomas


Dominick



On Wed, Jan 18, 2023 at 12:56 PM Tomas Kalibera <tomas.kalibera at gmail.com>
wrote:

On 1/18/23 17:39, Dominick Samperi wrote:

Thanks,

But this didn't work. It installs msys2 along with lots of other stuff,
and gdb would not start as before (missing DLL's).

Then I tried to run the command you suggested again, and there was a
warning from the package manager about a cycle detected, but now gdb starts
with the following messages...

Well, so it did work in the end. You didn't share what was the output
from the command the first and second time around. Actually you have even
deleted the command from the thread, so now nobody can see it (it was
"pacman -Syuu").

In principle, sometimes one has to re-run the update the second time
when the runtime needs to be updated, and the output says that in that
case. This is because you are updating Msys2 from Msys2 itself. These
things are harder on Windows due to file locking, hence the need for
re-running this.

What happened is probably (but again, I have to be guessing as you
didn't show the context) that you have installed gdb to an outdated Msys2
installation, getting a new version of gdb depending on some new runtime
shared libraries. By updating Msys2, you got the new shared libraries gdb
needed and you could run it.


Traceback (most recent call last):
  File "<string>", ine 3, in <module>
ModuleNotFoundError: No module named 'libstdcxx'
/etc/gdbinit:5: Error in sourced command file:
Error while executing Python code.

It is safe and best to ignore this. It is a bug in Msys2 which has been
reported.
https://github.com/msys2/MSYS2-packages/issues/2923

Please also note it is documented in
https://cran.r-project.org/bin/windows/base/howto-R-4.2.html
(see Additional debugging hints)


There is also a line...

This GDB was configured as "x86_64_pc-msys".

(Shouldn't that be msys2?)

No. Msys2 is the name for the whole project. "msys" is the name of one
of subsystem, one which uses the msys (cygwin) runtime. It is not necessary
to understand these details for using Msys2/Rtools42, but if you are still
interested to know more, please refer to Msys2 documentation.

If I ignore the messages and try to debug a terminal application, there
are messages
stating that multiple threads are started, and the application accepts
no keyboard
input, and ultimately must be terminated by closing the window.

Please really you need to show more context to get help. I am using this
every day and it works for me, as well as for other people. Also, please
read the documentation especially if you are running into problems:

https://cran.r-project.org/bin/windows/base/howto-R-4.2.html
https://cran.r-project.org/bin/windows/base/howto-R-devel.html

Problems with keyboard input are probably related to which terminal you
are using. In some terminals, you would have to use winpty (run gdb with
winpty) for line editing to work. Please see "Additional debugging hints"
in the documentation.

In a clean, updated install of Rtools42, with gdb installed as
documented, no additional tweaks are needed to run gdb from the "Rtools42
bash" (mintty terminal running bash from Msys2).

It appears there are other development communities negatively impacted by
the fork to mingw-w64. This did not go smoothly.

I don't understand what you mean. As far as I know, R has been using
MinGW-W64 (and before that MinGW) from the beginning, certainly it has been
using MinGW-W64 for many years now. The official builds never used MSVC,
there was no switching to MinGW/MinGW-W64 in the case of R afair, at least
not in the recent past.

But, in either case, the choice of MinGW-W64 is orthogonal to the choice
of Msys2 as the provider of the build tools. Rtools42/43 come also in a
compiler toolchain+libraries bundle, without Msys2, which in theory you
could use with a different set of build tools. But you would be on your own
to figure out the details.


Perhaps it would be safer to simply provide a version of Rtools42 that
comes with
gdb and msys2?

Rtools42 comes with Msys2. gdb is not installed there by default,
because most people don't need it, but it is documented how to install it.
I've now updated the documentation to always remind to update the system
before installing any Msys2 packages.

Tomas


Dominick




On Wed, Jan 18, 2023 at 2:40 AM Tomas Kalibera <tomas.kalibera at gmail.com>
wrote:

On 1/18/23 04:33, Dominick Samperi wrote:

Hello,

I tried installing gdb into Rtools42 following the instructions here
https://cran.r-project.org/bin/windows/base/howto-R-4.2.html

I ran 'pacman -Sy gdb', and the installation seemed to complete

without

problems.

But gdb could not be started because incorrect DLL versions were

installed,

in particular, the missing DLL's are: msys-ffi-8.dll and
msys-unistring-5.dll.

Try upgrading Msys2 using

pacman -Syuu

Tomas

Is there an alternative way to install gdb for use with Rtool42?

Thanks,
Dominick

      [[alternative HTML version deleted]]

______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Dirk Eddelbuettel

Wed, Jan 18, 2023 7:56 PM #

On 18 January 2023 at 22:44, Dominick Samperi wrote:

| On second thought, there is a lot of metapramming code in Rcpp that runs
| before main, so
| I was wrong to say nothing can happen before main() is called.
| Strategically placed print
| statements may be the best strategy.

Yes, and if you want to rule our Rcpp / RInside you can try to embed R
directly without these two and see if you get your repl + plotting device
going without. There is some basic documentation about embedding in section 8
in https://rstudio.github.io/r-manuals/r-exts/ (more nicely rendered version
of the standard manual).

The manual also has a special section on Window -- and while do not do that
much in RInside and Rcpp that is platform specific it is always possible that
we have a bug here or there. That said, there have always been embedded uses
of RInside on Windows too. Good luck, and let us know if you find bugs.

Dirk

dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Thu, Jan 19, 2023 2:13 AM #

On 1/19/23 04:44, Dominick Samperi wrote:

You can insert breakpoints into the code which runs before main() as 
well. With C++, these may be constructors for static and global objects. 
gdb calls this "elaboration phase", see their documentation. Right, 
adding print statements (to output, or to files with GUI) may sometimes 
be useful as well. Also you can add some checks to the code and crash it 
intentionally when something happens, that way you get to the debugger 
as well if you ran your program in it. On Windows, you can also enter 
the debugger programmatically without crashing, with an interrupt (see 
breaking to debugger in Rgui). On Windows, you can also set windbg to be 
the post-mortem debugger, invoked automatically when the program 
crashes. But most of this is probably already off topic for this list. 
Some of these things are mentioned in 
https://cran.r-project.org/bin/windows/base/howto-R-devel.html.

Tomas

On Wed, Jan 18, 2023 at 8:17 PM Dominick Samperi <djsamperi at gmail.com> 
wrote:

    Since these ?stray threads? were appearing before I installed gdb
    into Rtools42, this may be an operating system bug, and not a
    problem with gdb or RInside!

    Sent from my iPhone

    On Jan 18, 2023, at 6:08 PM, Dominick Samperi
    <djsamperi at gmail.com> wrote:

    ?
    There may be a more serious problem with gdb, or perhaps a very
    subtle
    problem in the RInside package repl function that only appears under
    Windows (I reported this in the Rcpp-devel list, where I provided
    a small example repl.cpp with Makefile for Windows).

    Gdb is invoked as 'gdb repl.exe', a breakpoint is set on main,
    and the gdb run
    command is entered. Gdb should simply stop at main and wait for
    the next
    command. But instead the program seems to be run, its GUI pops
    up, and
    after a few seconds it terminates and Gdb finally hits main,
    waiting for
    the next command!

    This strange behavior does not happen under Linux where the
    program runs normally, gdb starts only one thread (see below),
    and gdb behaves as you would expect it to.

    Normally gdb starts about four threads under Windows, one for the
    program
    to be debugged, and three worker threads. Under Linux/Ubuntu this
    doesn't
    happen, only one thread is created. I'm not sure what the worker
    threads
    are used for.

    What seems to be happening here is a stray thread is created for
    the program,
    one for which the breakpoint doesn't apply, and this thread runs
    before the
    main thread running the desired instance of the program hits the
    breakpoint.

    At this point the instance of the program running in the main
    program is
    doomed because you cannot start an embedded instance of R more
    than once in the same compilation unit, and the stray thread already
    started one.

    There does seem to be a subtle issue in the repl program under
    Windows
    that is not related to gdb, but this doesn't explain why gdb
    creates that stray
    thread, making it impossible to proceed with the debugging. Nothing
    should happen before gdb hits main, even if there is a bug in repl.

    It is possible that static constructors need to be run before main,
    but this wouldn't result in the main program block being executed.

    Dominick

    On Wed, Jan 18, 2023 at 2:10 PM Tomas Kalibera
    <tomas.kalibera at gmail.com> wrote:


        On 1/18/23 19:41, Dominick Samperi wrote:

        Thanks for the detailed feedback Tomas,

        I ran the command 'pacman -Syuu' again, just to be sure, and
        this time it says "there is nothing to do."

        It appears that gdb is working. I was spooked by the
        diagnostics that you say is a known (not serious) issue.

        My mistake was not setting a breakpoint on main, so I
        confused problems with gdb with problems with the program
        I'm trying to debug!

        I am glad it works now for you. Please don't forget to
        include debug info (for R or packages, depending on what you
        need to debug).

        Incidentally, my remark about mingw-w64 problems in other
        communities alluded to the Haskell development
        community, where an ABI incompatibility was discovered about
        a year ago. It is discussed by Ben Gamari here
        https://gitlab.haskell.org/ghc/ghc/-/issues/19945.

        From a quick look it seems to be an incompatibility between
        two libraries implementing POSIX regular expressions,
        essentially a name clash, they just need to make sure to
        consistently use one of them. It is not a problem of MinGW-W64.

        Tomas

        Dominick



        On Wed, Jan 18, 2023 at 12:56 PM Tomas Kalibera
        <tomas.kalibera at gmail.com> wrote:

            On 1/18/23 17:39, Dominick Samperi wrote:

            Thanks,

            But this didn't work. It installs msys2 along with lots
            of other stuff, and gdb would not start as before
            (missing DLL's).

            Then I tried to run the command you suggested again,
            and there was a warning from the package manager about
            a cycle detected, but now gdb starts with the following
            messages...

            Well, so it did work in the end. You didn't share what
            was the output from the command the first and second
            time around. Actually you have even deleted the command
            from the thread, so now nobody can see it (it was
            "pacman -Syuu").

            In principle, sometimes one has to re-run the update the
            second time when the runtime needs to be updated, and
            the output says that in that case. This is because you
            are updating Msys2 from Msys2 itself. These things are
            harder on Windows due to file locking, hence the need
            for re-running this.

            What happened is probably (but again, I have to be
            guessing as you didn't show the context) that you have
            installed gdb to an outdated Msys2 installation, getting
            a new version of gdb depending on some new runtime
            shared libraries. By updating Msys2, you got the new
            shared libraries gdb needed and you could run it.

            Traceback (most recent call last):
            ? File "<string>", ine 3, in <module>
            ModuleNotFoundError: No module named 'libstdcxx'
            /etc/gdbinit:5: Error in sourced command file:
            Error while executing Python code.

            It is safe and best to ignore this. It is a bug in Msys2
            which has been reported.
            https://github.com/msys2/MSYS2-packages/issues/2923

            Please also note it is documented in
            https://cran.r-project.org/bin/windows/base/howto-R-4.2.html
            (see Additional debugging hints)

            There is also a line...

            This GDB was configured as "x86_64_pc-msys".

            (Shouldn't that be msys2?)

            No. Msys2 is the name for the whole project. "msys" is
            the name of one of subsystem, one which uses the msys
            (cygwin) runtime. It is not necessary to understand
            these details for using Msys2/Rtools42, but if you are
            still interested to know more, please refer to Msys2
            documentation.

            If I ignore the messages and try to debug a terminal
            application, there are messages
            stating that multiple threads are started, and the
            application accepts no keyboard
            input, and ultimately must be terminated by closing the
            window.

            Please really you need to show more context to get help.
            I am using this every day and it works for me, as well
            as for other people. Also, please read the documentation
            especially if you are running into problems:

            https://cran.r-project.org/bin/windows/base/howto-R-4.2.html
            https://cran.r-project.org/bin/windows/base/howto-R-devel.html

            Problems with keyboard input are probably related to
            which terminal you are using. In some terminals, you
            would have to use winpty (run gdb with winpty) for line
            editing to work. Please see "Additional debugging hints"
            in the documentation.

            In a clean, updated install of Rtools42, with gdb
            installed as documented, no additional tweaks are needed
            to run gdb from the "Rtools42 bash" (mintty terminal
            running bash from Msys2).

            It appears there are other development communities
            negatively impacted by
            the fork to mingw-w64. This did not go smoothly.

            I don't understand what you mean. As far as I know, R
            has been using MinGW-W64 (and before that MinGW) from
            the beginning, certainly it has been using MinGW-W64 for
            many years now. The official builds never used MSVC,
            there was no switching to MinGW/MinGW-W64 in the case of
            R afair, at least not in the recent past.

            But, in either case, the choice of MinGW-W64 is
            orthogonal to the choice of Msys2 as the provider of the
            build tools. Rtools42/43 come also in a compiler
            toolchain+libraries bundle, without Msys2, which in
            theory you could use with a different set of build
            tools. But you would be on your own to figure out the
            details.

            Perhaps it would be safer to simply provide a version
            of Rtools42 that comes with
            gdb and msys2?

            Rtools42 comes with Msys2. gdb is not installed there by
            default, because most people don't need it, but it is
            documented how to install it. I've now updated the
            documentation to always remind to update the system
            before installing any Msys2 packages.

            Tomas

            Dominick




            On Wed, Jan 18, 2023 at 2:40 AM Tomas Kalibera
            <tomas.kalibera at gmail.com> wrote:


                On 1/18/23 04:33, Dominick Samperi wrote:

                > Hello,
                >
                > I tried installing gdb into Rtools42 following

                the instructions here

                https://cran.r-project.org/bin/windows/base/howto-R-4.2.html

                >
                > I ran 'pacman -Sy gdb', and the installation

                seemed to complete without

                > problems.
                >
                > But gdb could not be started because incorrect

                DLL versions were installed,

                > in particular, the missing DLL's are:

                msys-ffi-8.dll and

                > msys-unistring-5.dll.

                Try upgrading Msys2 using

                pacman -Syuu

                Tomas

                > Is there an alternative way to install gdb for

                use with Rtool42?

                >
                > Thanks,
                > Dominick
                >
                >? ? ? ?[[alternative HTML version deleted]]
                >
                > ______________________________________________
                > R-devel at r-project.org mailing list
                > https://stat.ethz.ch/mailman/listinfo/r-devel