Dear sir,
Thank you for your reply and suggestions. Gdb is exactly the thing I was
looking for. Will certainly report the bug on R-devel if found so.
regards,
Pulkit
On Fri, Feb 8, 2013 at 9:52 AM, Martin Morgan <mtmor...@fhcrc.org> wrote:
> On 02/08/2013 05:13 AM, Pulkit Mehrotra wrote:
>
>> hello,
>>
>> I was having some problems in debugging C codes assocaited with
>> R-packages.
>> I don't have much experience with debugging tools used in C language. Is
>> there any methods similar to R-debugging tools such as browser ,debug etc
>> which can be used to debug such C files.
>>
>> I was using the foreign package and found a bug in reading dta files
>> containing empty strings "" in the data. I was able to find where the
>> error
>> originated in the R file but was unable to do so for the C files.
>>
>> Any help would be deeply appreciated.
>>
>> Thank you for your time and consideration.
>>
>
> For debugging package code at the C level, one usually starts (on
> non-Windows) by installing the package without any compiler optimizations,
> e.g., by following
>
> RShowDoc("R-admin")
>
> section 6.3.3. setting for instance
>
> CFLAGS="-g -O0"
>
> in .R/Makevars.
>
> Then when the bug is isolated and easily produced in a script buggy.R
> start R with a C-level debugger such as gdb (this is an old-school
> command-line style debugger, not to everyone's taste)
>
> R -d gdb -f buggy.R
>
> You'll end up at the gdb prompt
>
> gdb>
>
> and a typical operation is to (r)un or (c)ontinue execution
>
> gdb> r
>
> to run buggy.R. You'll end up back in C when there is a segfault, or you
> press cntrl-C, or when you've inserted a breakpoint at some C-level
> function that you suspect is buggy, e.g.,
>
> > ^C
> gdb> b some_buggy_fun
> gdb> c
>
> When you do end up back in the debugger, you can print C variables or the
> C representation of R variables
>
> gdb> p c_var
> gdb> call Rf_PrintValue(some_R_variable)
>
> go (u)p and (d)own the call stack, etc. See
>
> gdb> help
>
> and of course our mutual friend Google.
>
> But this is not for the faint of heart and requires some C-level
> familiarity. It might also be possible to spot the bug with
>
> R -d valgrind -f buggy.R
>
> which runs quite slowly and will also require C familiarity to interpret
> output. Again it is helpful to run the buggy code with a package that has
> been installed without compiler optimizations. See section 4.3 of
> RShowDoc("R-exts")
>
> Good luck!
>
> Martin
>
>
>> with regards,
>> Pulkit Mehrotra
>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________**________________
>> R-help@r-project.org mailing list
>> https://stat.ethz.ch/mailman/**listinfo/r-help<https://stat.ethz.ch/mailman/listinfo/r-help>
>> PLEASE do read the posting guide http://www.R-project.org/**
>> posting-guide.html <http://www.R-project.org/posting-guide.html>
>> and provide commented, minimal, self-contained, reproducible code.
>>
>>
>
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>
[[alternative HTML version deleted]]
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
