Skip to content

[Rcpp-devel] R.e. Debugging Rcpp packages with GDB

9 messages · Christian Gunning, Dirk Eddelbuettel, Davor Cubranic +2 more

Christian Gunning
# 
On Tue, Jan 18, 2011 at 2:46 PM,
<rcpp-devel-request at lists.r-forge.r-project.org> wrote:
It's not very sophisticated, but I find that much of the time adding
Rf_PrintValue(xx) calls to code gives me as much info as I need.  If
it's a non-SEXP object like int, then Rf_PrintValue(wrap(my_int)).
I have 2 related "simple questions" after reading through Chapters 1
and 4 of "Writing R Extensions":

My build/test chain is:

R CMD INSTALL mypackage
R --vanilla --debugger gdb
run
require(mypackage)
<test in R>
quit()
<edit code>
R CMD INSTALL mypackage
run
require(mypackage) ## reload package with edits
<lather, rinse, repeat>

1)  Is there a "best" way to reload the shared library after
rebuilding it? dyn.unload() and dyn.load()?

2) Is there a simple way to include debugging symbols/keep values from
getting optimized out when building with Rcpp?

Thanks,
Christian

  
    

      
      
    

  


  


    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 18 January 2011 at 15:52, Christian Gunning wrote:

        
| On Tue, Jan 18, 2011 at 2:46 PM,

        
| <rcpp-devel-request at lists.r-forge.r-project.org> wrote:

        
| >
| > Can people share any tricks they use to debug Rcpp packages? For example, can I "print" variables in a format that's a bit more high-level, like something that I would get if I sent them to "cout"?
| >
| 
| It's not very sophisticated, but I find that much of the time adding
| Rf_PrintValue(xx) calls to code gives me as much info as I need.  If
| it's a non-SEXP object like int, then Rf_PrintValue(wrap(my_int)).
| 
| > If that's not entirely obvious from my question, I am not a GDB expert. :-) Basically, my workflow is: "attach to the R process", "set a breakpoint at the function entry point", "single-step and print variable values". I have used watches and conditional breakpoints in GUI debuggers, but not (yet) in gdb. Are there any Rcpp-specific gotchas to using those features with GDB?
| 
| I have 2 related "simple questions" after reading through Chapters 1
| and 4 of "Writing R Extensions":
| 
| My build/test chain is:
| 
| R CMD INSTALL mypackage
| R --vanilla --debugger gdb
| run
| require(mypackage)
| <test in R>
| quit()
| <edit code>
| R CMD INSTALL mypackage
| run
| require(mypackage) ## reload package with edits
| <lather, rinse, repeat>
| 
| 1)  Is there a "best" way to reload the shared library after
| rebuilding it? dyn.unload() and dyn.load()?

I am partial to littler. Eg sometimes I just do

  $ R CMD INSTALL foo && r -lfoo -e'someExpressionIWantToTest()'
 
Because the 'r' (littler) starts fresh sessions I do not need to worry about
unload.   In other cases I use inline -- it depends.

| 2) Is there a simple way to include debugging symbols/keep values from
| getting optimized out when building with Rcpp?

You could always include -g and then strip what you don't need -- which is 
what Debian and Ubuntu do to give you the *-dbg packages.  

R sits on top of Makefile logic, and make is pretty powerful language.  You
can (literally) do just about anything....   Setting CFGLAGS / CXXFLAGS or
their PKG_* variants is probably easiest.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Douglas Bates
    

    

      
      #
    

  


  

      
On Tue, Jan 18, 2011 at 6:19 PM, Dirk Eddelbuettel <edd at debian.org> wrote:

            

      
      
      
    

        
Or create a file $HOME/.R/Makevars and define CXXFLAGS and CFLAGS in
there.  I have the following contents

CFLAGS= -g -pipe -std=gnu99 -Wall -pedantic
CFLAGS= -g -O3 -pipe -std=gnu99 -Wall -pedantic
CXXFLAGS= -g -pipe -Wall -pedantic
CXXFLAGS= -g -pipe -std=c++0x -Wall -pedantic
CXXFLAGS= -g -O3 -pipe -Wall -pedantic
CXXFLAGS= -g -O3 -pipe -std=c++0x -Wall -pedantic

and comment out the trailing lines if I want to suppress the c++0x
standard or the optimization when using the debugger.

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 19 January 2011 at 08:43, Douglas Bates wrote:

        
| > | 2) Is there a simple way to include debugging symbols/keep values from
| > | getting optimized out when building with Rcpp?
| >
| > You could always include -g and then strip what you don't need -- which is
| > what Debian and Ubuntu do to give you the *-dbg packages.
| >
| > R sits on top of Makefile logic, and make is pretty powerful language. ?You
| > can (literally) do just about anything.... ? Setting CFGLAGS / CXXFLAGS or
| > their PKG_* variants is probably easiest.
| 
| Or create a file $HOME/.R/Makevars and define CXXFLAGS and CFLAGS in
| there.  I have the following contents
| 
| CFLAGS= -g -pipe -std=gnu99 -Wall -pedantic
| CFLAGS= -g -O3 -pipe -std=gnu99 -Wall -pedantic
| CXXFLAGS= -g -pipe -Wall -pedantic
| CXXFLAGS= -g -pipe -std=c++0x -Wall -pedantic
| CXXFLAGS= -g -O3 -pipe -Wall -pedantic
| CXXFLAGS= -g -O3 -pipe -std=c++0x -Wall -pedantic
| 
| and comment out the trailing lines if I want to suppress the c++0x
| standard or the optimization when using the debugger.

Seconded. 

That is actually what I do, including the better-than-awesome ccache:

edd at max:~$ cat .R/Makevars
# edd 03 Mar 2009

## for C code
CFLAGS=-g -O3 -Wall -pipe -pedantic -std=gnu99
#CFLAGS=-O3 -g0 -Wall -pipe -std=gnu99
## for C++ code
CXXFLAGS= -g -O3 -Wall -pipe -pedantic -Wno-variadic-macros
#CXXFLAGS= -g0 -O3 -Wall -pipe -Wno-variadic-macros
#CXXFLAGS= -O3 -g0 -Wall -pipe 
## for Fortran code
#FFLAGS=-g -O3 -Wall -pipe
FFLAGS=-O3 -g0 -Wall -pipe
## for Fortran 95 code
#FCFLAGS=-g -O3 -Wall -pipe
FCFLAGS=-O3 -g0 -Wall -pipe

CC=ccache gcc
CXX=ccache g++
FC=ccache gfortran
F77=ccache gfortran
MAKE=make -j4
edd at max:~$ 


The -Wno-variadic-macros was once needed when Romain was a tad more
aggressive in trying new C++0x features.  

The 'make -j4' also takes care of parallel builds.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Christian Gunning
    

    

      
      #
    

  


  

      
Thanks all for the crash course - it works great!

I just cobbled up a simple "reload" function. This has been a
long-standing pet peeve of mine -- anything that makes me leave the R
shell is distracting.  I've tested it and it seems to work just fine.
Are there any non-obvious downsides here?

reload = function(pkgname, preload=TRUE) {
    ## load it
    if (preload) {
        library(pkgname, character.only = TRUE)
    }
    libs <- dir(paste(.path.package(pkgname), '/libs', sep=''), full.names=TRUE)
    for (lib in libs) {
        dyn.unload(lib)
        dyn.load(lib)
    }
    return()
}

best,
Christian

        
On Wed, Jan 19, 2011 at 8:01 AM, Dirk Eddelbuettel <edd at debian.org> wrote:

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    
4 days later

    

      
      

        


  

        

      Davor Cubranic
    

    

      
      #
    

  


  

      
To follow up my original post, it is possible to define GDB pretty-printers using Python. (See http://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing.html.) Would people be interested in having Rcpp-specific pretty printers?

Davor

        
On 2011-01-19, at 7:01 AM, Dirk Eddelbuettel wrote:

        

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 24 January 2011 at 16:36, Davor Cubranic wrote:

        
| To follow up my original post, it is possible to define GDB pretty-printers using Python. (See http://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing.html.) Would people be interested in having Rcpp-specific pretty printers?

That would be great. I have read about this feature ever since gcb 7.0 was
announced but have never used. It probably would make a lot of sense here.

Dirk
 
| Davor
|

        
| On 2011-01-19, at 7:01 AM, Dirk Eddelbuettel wrote:

        
| 
| >

        
| > On 19 January 2011 at 08:43, Douglas Bates wrote:

        
| > | > | 2) Is there a simple way to include debugging symbols/keep values from
| > | > | getting optimized out when building with Rcpp?
| > | >
| > | > You could always include -g and then strip what you don't need -- which is
| > | > what Debian and Ubuntu do to give you the *-dbg packages.
| > | >
| > | > R sits on top of Makefile logic, and make is pretty powerful language.  You
| > | > can (literally) do just about anything....   Setting CFGLAGS / CXXFLAGS or
| > | > their PKG_* variants is probably easiest.
| > | 
| > | Or create a file $HOME/.R/Makevars and define CXXFLAGS and CFLAGS in
| > | there.  I have the following contents
| > | 
| > | CFLAGS= -g -pipe -std=gnu99 -Wall -pedantic
| > | CFLAGS= -g -O3 -pipe -std=gnu99 -Wall -pedantic
| > | CXXFLAGS= -g -pipe -Wall -pedantic
| > | CXXFLAGS= -g -pipe -std=c++0x -Wall -pedantic
| > | CXXFLAGS= -g -O3 -pipe -Wall -pedantic
| > | CXXFLAGS= -g -O3 -pipe -std=c++0x -Wall -pedantic
| > | 
| > | and comment out the trailing lines if I want to suppress the c++0x
| > | standard or the optimization when using the debugger.
| > 
| > Seconded. 
| > 
| > That is actually what I do, including the better-than-awesome ccache:
| > 
| > edd at max:~$ cat .R/Makevars
| > # edd 03 Mar 2009
| > 
| > ## for C code
| > CFLAGS=-g -O3 -Wall -pipe -pedantic -std=gnu99
| > #CFLAGS=-O3 -g0 -Wall -pipe -std=gnu99
| > ## for C++ code
| > CXXFLAGS= -g -O3 -Wall -pipe -pedantic -Wno-variadic-macros
| > #CXXFLAGS= -g0 -O3 -Wall -pipe -Wno-variadic-macros
| > #CXXFLAGS= -O3 -g0 -Wall -pipe 
| > ## for Fortran code
| > #FFLAGS=-g -O3 -Wall -pipe
| > FFLAGS=-O3 -g0 -Wall -pipe
| > ## for Fortran 95 code
| > #FCFLAGS=-g -O3 -Wall -pipe
| > FCFLAGS=-O3 -g0 -Wall -pipe
| > 
| > CC=ccache gcc
| > CXX=ccache g++
| > FC=ccache gfortran
| > F77=ccache gfortran
| > MAKE=make -j4
| > edd at max:~$ 
| > 
| > 
| > The -Wno-variadic-macros was once needed when Romain was a tad more
| > aggressive in trying new C++0x features.  
| > 
| > The 'make -j4' also takes care of parallel builds.
| > 
| > Dirk
| > 
| > -- 
| > Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
| > _______________________________________________
| > Rcpp-devel mailing list
| > Rcpp-devel at lists.r-forge.r-project.org
| > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
|

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Andrew Redd
    

    

      
      #
    

  


  

      
Davor,

A good place to start might be to mirror the behavior of the str in base R.
 That gives quick truncated information, the kind that is helpful in
debugging.

-Andrew

        
On Mon, Jan 24, 2011 at 7:55 PM, Dirk Eddelbuettel <edd at debian.org> wrote:

        

            

      
      
      
    

        

      
      
    

        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20110124/8b8a3441/attachment.htm>

  
  


  


      

    

    

      
      

        


  

        

      Douglas Bates
    

    

      
      #
    

  


  

      
On Mon, Jan 24, 2011 at 9:10 PM, Andrew Redd <amredd at gmail.com> wrote:

            

      
      
      
    

        
There is an internal function in R called inspect that does some of
that.  I think Simon wrote it for a particularly difficult debugging
problem.  Unfortunately it is not exported as part of the R API and,
as far as I can see, only be called as an .Internal call from R

            

      
      
      
    

        
@20f1420 13 INTSXP g0c4 [NAM(1)] (len=10, tl=0) 1,2,3,4,5,...

            

      
      
      
    

        
@3195728 19 VECSXP g0c3 [ATT] (len=3, tl=0)
  @3195800 16 STRSXP g0c3 [] (len=4, tl=0)
    @2804c28 09 CHARSXP g0c1 [gp=0x20] "A"
    @2804bf8 09 CHARSXP g0c1 [gp=0x20] "B"
    @20cb5b8 09 CHARSXP g0c1 [MARK,gp=0x21] "C"
    @1eff388 09 CHARSXP g0c1 [MARK,gp=0x21] "D"
  @319d518 13 INTSXP g0c2 [] (len=3, tl=0) 10,11,12
  @28048f8 14 REALSXP g0c1 [] (len=1, tl=0) 3.14159
ATTRIB:
  @28059f0 02 LISTSXP g0c0 []
    TAG: @1ec21a8 01 SYMSXP g0c0 [MARK,NAM(2),gp=0x4000] "names"
    @31956e0 16 STRSXP g0c3 [] (len=3, tl=0)
      @202e288 09 CHARSXP g0c1 [MARK,gp=0x21] "a"
      @1ff31f8 09 CHARSXP g0c1 [MARK,gp=0x21] "b"
      @1ee5528 09 CHARSXP g0c1 [MARK,gp=0x21] "c"

I'll suggest exporting the underlying function inspect.