headers
Christian Gunning | 18 Jan 2011 23:52
Picon
Favicon

R.e. Debugging Rcpp packages with GDB

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
(Continue reading)

Permalink | Reply |
headers
Dirk Eddelbuettel | 19 Jan 2011 01:19
Picon
Favicon
Gravatar

Re: R.e. Debugging Rcpp packages with GDB


On 18 January 2011 at 15:52, Christian Gunning wrote:
| On Tue, Jan 18, 2011 at 2:46 PM,
| <rcpp-devel-request@...> 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>
(Continue reading)

Permalink | Reply |
headers
Douglas Bates | 19 Jan 2011 15:43
Picon
Favicon

Re: R.e. Debugging Rcpp packages with GDB

On Tue, Jan 18, 2011 at 6:19 PM, Dirk Eddelbuettel <edd@...> wrote:
>
> On 18 January 2011 at 15:52, Christian Gunning wrote:
> | On Tue, Jan 18, 2011 at 2:46 PM,
> | <rcpp-devel-request@...> 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()
(Continue reading)

Permalink | Reply |
headers
Dirk Eddelbuettel | 19 Jan 2011 16:01
Picon
Favicon
Gravatar

Re: R.e. Debugging Rcpp packages with GDB


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
(Continue reading)

Permalink | Reply |
headers
Christian Gunning | 20 Jan 2011 06:19
Picon
Favicon

Re: R.e. Debugging Rcpp packages with GDB

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:
>
> 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
(Continue reading)

Permalink | Reply |
headers
Davor Cubranic | 25 Jan 2011 01:36
Picon
Picon
Gravatar

Re: R.e. Debugging Rcpp packages with GDB

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:

> 
> 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
> |
(Continue reading)

Permalink | Reply |
headers
Dirk Eddelbuettel | 25 Jan 2011 03:55
Picon
Favicon
Gravatar

Re: R.e. Debugging Rcpp packages with GDB


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
| > |
(Continue reading)

Permalink | Reply |
headers
Andrew Redd | 25 Jan 2011 04:10
Picon
Gravatar

Re: R.e. Debugging Rcpp packages with GDB

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-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> wrote:

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-8fiUuRrzOP0dnm+yROfE0A@public.gmane.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
|

--
Dirk Eddelbuettel | edd-8fiUuRrzOP0dnm+yROfE0A@public.gmane.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

_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@...
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Permalink | Reply |
headers
Douglas Bates | 25 Jan 2011 15:11
Picon
Favicon

Re: R.e. Debugging Rcpp packages with GDB

On Mon, Jan 24, 2011 at 9:10 PM, Andrew Redd <amredd@...> wrote:
> 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

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

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

I'll suggest exporting the underlying function inspect.
> On Mon, Jan 24, 2011 at 7:55 PM, Dirk Eddelbuettel <edd@...> wrote:
>>
>> 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@... | http://dirk.eddelbuettel.com
>> | > _______________________________________________
>> | > Rcpp-devel mailing list
>> | > Rcpp-devel@...
>> | >
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>> |
>>
>> --
>> Dirk Eddelbuettel | edd@... | http://dirk.eddelbuettel.com
>> _______________________________________________
>> Rcpp-devel mailing list
>> Rcpp-devel@...
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
>
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel@...
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
>
Permalink | Reply |

Gmane