From sdavis2 at mail.nih.gov  Tue Jan 10 22:17:41 2006
From: sdavis2 at mail.nih.gov (Sean Davis)
Date: Tue, 10 Jan 2006 16:17:41 -0500
Subject: [Rd] Issue with c++ .C call
In-Reply-To: <Pine.LNX.4.64.0601101115500.25401@homer24.u.washington.edu>
Message-ID: <BFE98EA5.36AA%sdavis2@mail.nih.gov>




On 1/10/06 2:27 PM, "Thomas Lumley" <tlumley at u.washington.edu> wrote:

> On Tue, 10 Jan 2006, Sean Davis wrote:
>> and such.  However, the call to the function is via .C; parameters from the
>> .C call are not being passed correctly to the function.  As an example, I
>> have attached a GDB run of the code.  I set a breakpoint on entry to the
>> function I am calling from R.  What is bothering me (and probably causing
>> the segmentation faults I am seeing) is that the parameter
>> prm=as.double(c(3.2,1.1)) is not 3.2,1.1 IMMEDIATELY after the call to .C.
> 
> Is this compiled with optimization? If so, you can't conclude much from
> the gdb info as the code can be executed in a different order from how
> it's written.
> 
> When I use this example
> 
> extern "C" void calcStepgram(double *data,  double *prm, double *intervals,
> int *max, int *n,double *plot) {
> 
>   prm[0]=data[0];
>   return;
> }
> 
> if I compile with -g -02 (the default) it looks as though there are
> problems with initialization like the ones you report, but in fact the
> function works correctly.  If I compile without optimization the
> initialization looks fine.

Thanks, Thomas.  That did fix the initialization issue (or apparent one).
Unfortunately, the reason that I started debugging was for segmentation
faults, which have not gone away.  However, it now looks like the problem is
internal to the C++ code and not with the way the arguments were being
passed.  

Back to gdb....

Sean



[Rd] Issue with c++ .C call
Sean Davis