Data.table: Using cc/dd helper functions for data.table dev

Created on 18 Apr 2018  路  1Comment  路  Source: Rdatatable/data.table

I use cc() and dd() for C dev, extremely useful, but when I am in C after setting breakpoint I don't know how to proceed. Is there any R str/ls equivalent in C? can I use this gdb in interactive way as debugging in R? What is the best way to proceed from such place?

Breakpoint 1, rollmean (obj=0x41d26b0, k=0x41cf9e8, fill=0x41cf9b8)
    at roll.c:49
49          double *rx = REAL(VECTOR_ELT(tmp, m));
(gdb)

Any good materials about understanding how to use it it would be even better.

question

Most helpful comment

Great question! Really pleased to be seeing C questions here.
R-exts$4.4.2 contains this text :

Another way is to call R_PV from the symbolic debugger. (PrintValue is hidden as Rf_PrintValue.) For example, from gdb we can use
(gdb) p R_PV(ab)

But I've never been able to get R_PV to work. That might be due to the way R is compiled for Ubuntu, or the way I compile R-devel, or maybe I'm remembering incorrectly. Anyway, what I do is

(gdb) p Rf_PrintValue(ab)

and I find that works; i.e. it prints the SEXP object as you would see it at the regular R prompt.

R_inspect is mentioned in that section too, which is like str(). I haven't used that for a long time. If it doesn't work then I would try Rf_inspect or even Rf_R_inspect.

In terms of listing all variables, I had to remind myself and did a google search "show all variables in gdb" which gave this as first link : https://stackoverflow.com/questions/6261392/printing-all-global-variables-local-variables, so that's :

(gdb) info locals

You can try (gdb) help, (gdb) help status and (gdb) help running but there's so much there it can be hard to navigate. I tend to use a very limited subset of what's possible, just: c, n, break and clear. Stepping through R using browser() then into C and back again works nicely so long as you set a break point appropriately in C first. Other than that, I have used a hardware-watchpoint once (under the guidance Luke Tierney) -- that magic command should probably be documented somewhere if we ever need it again (I'd have to look it up from my email history).

Aside : when I use dd() I never have a problem setting breakpoints by line number; e.g. (gdb) break fread.c:1452. But I did find recently that didn't work when data.table is installed as opposed to being loaded in .GlobalEnv in dev mode as dd() does. It appeared that gdb found debug instrumentation in the .so, but it couldn't find the source files. So I just changed working directory to the /src directory in dev and then debugging worked fine, as an inelegant solution.

Finally: ensure the C code is compiled with -O0 before using gdb on it (using Makevars if installing, or dd() ensures that explicitly, which is why it re-compiles all C files each time just to be safe). Otherwise gdb will jump around the lines in a strange order due to effects of the C optimizer.

Closing question now just to remove from open list. Please reopen if follow up needed (all project members can reopen issues).

>All comments

Great question! Really pleased to be seeing C questions here.
R-exts$4.4.2 contains this text :

Another way is to call R_PV from the symbolic debugger. (PrintValue is hidden as Rf_PrintValue.) For example, from gdb we can use
(gdb) p R_PV(ab)

But I've never been able to get R_PV to work. That might be due to the way R is compiled for Ubuntu, or the way I compile R-devel, or maybe I'm remembering incorrectly. Anyway, what I do is

(gdb) p Rf_PrintValue(ab)

and I find that works; i.e. it prints the SEXP object as you would see it at the regular R prompt.

R_inspect is mentioned in that section too, which is like str(). I haven't used that for a long time. If it doesn't work then I would try Rf_inspect or even Rf_R_inspect.

In terms of listing all variables, I had to remind myself and did a google search "show all variables in gdb" which gave this as first link : https://stackoverflow.com/questions/6261392/printing-all-global-variables-local-variables, so that's :

(gdb) info locals

You can try (gdb) help, (gdb) help status and (gdb) help running but there's so much there it can be hard to navigate. I tend to use a very limited subset of what's possible, just: c, n, break and clear. Stepping through R using browser() then into C and back again works nicely so long as you set a break point appropriately in C first. Other than that, I have used a hardware-watchpoint once (under the guidance Luke Tierney) -- that magic command should probably be documented somewhere if we ever need it again (I'd have to look it up from my email history).

Aside : when I use dd() I never have a problem setting breakpoints by line number; e.g. (gdb) break fread.c:1452. But I did find recently that didn't work when data.table is installed as opposed to being loaded in .GlobalEnv in dev mode as dd() does. It appeared that gdb found debug instrumentation in the .so, but it couldn't find the source files. So I just changed working directory to the /src directory in dev and then debugging worked fine, as an inelegant solution.

Finally: ensure the C code is compiled with -O0 before using gdb on it (using Makevars if installing, or dd() ensures that explicitly, which is why it re-compiles all C files each time just to be safe). Otherwise gdb will jump around the lines in a strange order due to effects of the C optimizer.

Closing question now just to remove from open list. Please reopen if follow up needed (all project members can reopen issues).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mattdowle picture mattdowle  路  3Comments

st-pasha picture st-pasha  路  3Comments

alex46015 picture alex46015  路  3Comments

rafapereirabr picture rafapereirabr  路  3Comments

symbalex picture symbalex  路  3Comments