On 1/19/23 04: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.
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 <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
