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 <djsamp...@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 <djsamp...@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.kalib...@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.kalib...@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.kalib...@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@r-project.org mailing list >>>> > https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
