Skip to content

Problem installing gdb into Rtools42

8 messages · Tomas Kalibera, Dominick Samperi

Original
Dominick Samperi
# 
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.

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

Thanks,
Dominick
Tomas Kalibera
#
On 1/18/23 04:33, Dominick Samperi wrote:
Try upgrading Msys2 using

pacman -Syuu

Tomas
Dominick Samperi
# 
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...

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.

There is also a line...

This GDB was configured as "x86_64_pc-msys".

(Shouldn't that be msys2?)

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.

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

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

Dominick




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

  
  


  


      

    

    

      
      

        


  

        

      Tomas Kalibera
    

    

      
      #
    

  


  

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

            

      
      
      
    

        
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.

            

      
      
      
    

        
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)

            

      
      
      
    

        
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.

            

      
      
      
    

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

            

      
      
      
    

        
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.

            

      
      
      
    

        
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 Samperi
    

    

      
      #
    

  


  

      
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!

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.

Dominick



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

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Tomas Kalibera
    

    

      
      #
    

  


  

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

            

      
      
      
    

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

            

      
      
      
    

        
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 Samperi
    

    

      
      #
    

  


  

      
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 suble 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:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Dominick Samperi
    

    

      
      #
    

  


  

      
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: