[Rcppoctave-user] RcppOctave on Windows: testing needed

[Renaud Gaujoux]

Oh, true... this is scary...


On 10 October 2013 16:11, Dominick Samperi <djsamperi at gmail.com> wrote:

> BTW, in case this is not obvious, the function in strtest.cpp is
> not called at runtime! Thus the only way it could lead to problems
> is if the classes (like string_vector) need startup (static)
> initialization.
>
>
> On Thu, Oct 10, 2013 at 9:45 AM, Dominick Samperi <djsamperi at gmail.com>wrote:
>
>> Your modified strtest.cpp doesn't help:
>>
>> ** R
>> ** inst
>> ** preparing package for lazy loading
>> ** help
>> *** installing help indices
>> ** building package indices
>> ** installing vignettes
>> ** testing if installed package can be loaded
>> sh: line 1: 28714 Abort trap: 6
>> '/Library/Frameworks/R.framework/Resources/bin/R' --no-save --slave 2>&1 <
>> '/var/folders/fq/2th4vc9n1mq9cxv5nl9bmzkc0000gn/T//RtmpSQ4FV7/file6fc0345d6d7c'
>> R(28714) malloc: *** error for object 0x7fff7a01b570: pointer being freed
>> was not allocated
>> *** set a breakpoint in malloc_error_break to debug
>> ERROR: loading failed
>> * removing ‘/Users/dsamperi/Library/R/3.0/library/Rcpp’
>> * restoring previous ‘/Users/dsamperi/Library/R/3.0/library/Rcpp’
>>
>>
>> On Thu, Oct 10, 2013 at 4:18 AM, Renaud Gaujoux <
>> renaud at mancala.cbio.uct.ac.za> wrote:
>>
>>> Can you try with this modified version of the file?
>>> I wrapped the const char* strings into std::string, maybe this will make
>>> Mac happier.
>>>
>>> Let's communicate on this Mac issue off Rcpp-devel list for now on,
>>> since it is not directly related to Rcpp, but keep rcppoctave-user (where
>>> we are currently alone with Dirk :)). I will send a summary of the findings
>>> at the end. People that are keen to participate can subscribe to the
>>> rcppoctave-user list:
>>>
>>>
>>> http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcppoctave-user
>>>
>>>
>>>
>>>
>>> On 10 October 2013 07:01, Dominick Samperi <djsamperi at gmail.com> wrote:
>>>
>>>> It appears that there is some conflict between Rcpp and Octave under
>>>> Mac OS X that doesn't depend on the design of RcppOctave. Just
>>>> drop the files strtest.cpp and Makevars (attached) into Rcpp/src and
>>>> run R CMD INSTALL Rcpp. This leads to a memory error. The file
>>>> strtest.cpp was stripped out of rcpp_octave.cpp, but it does not
>>>> use RcppOctave or Rcpp (it is just a trivial Octave client).
>>>>
>>>> Since the problem is OS-dependent, it might have something do to
>>>> with static initializers in the Octave string_vector class, or perhaps
>>>> there
>>>> is a MacOS-specific conflict with std::string.
>>>>
>>>>
>>>>
>>>> On Wed, Oct 9, 2013 at 4:21 AM, Renaud Gaujoux <
>>>> renaud at mancala.cbio.uct.ac.za> wrote:
>>>>
>>>>> You are a resourceful person Dominick! :D
>>>>> I was not thinking in going Mac for now, because I can't test
>>>>> anything, but it will be great if we manage our way through it as well.
>>>>>
>>>>> 1. In src/modules/Makefile.in, the '-F' flag (for framework) is not
>>>>>>      recognized by mkoctfile, so I added this temporary work-around:
>>>>>>
>>>>>> #R_LDFLAGS = @R_LDFLAGS@
>>>>>> R_LDFLAGS = -L/Library/Frameworks/R.framework/Libraries -lR
>>>>>>
>>>>>
>>>>> One can probably test for Mac in configure.in and tweak the R_LDFLAGS
>>>>> for this platform only.
>>>>>
>>>>>>
>>>>>> 2. Parsing the man files o_whatever.Rd fails (attempt to
>>>>>>     free an unallocated pointer), so I removed all of these
>>>>>>     man pages for now (the failure occurs in
>>>>>>    <R>/src/library/tools/R/Rd.R, function .build_Rd_db(),
>>>>>>    where .fetch_Rd_object is applied to each Rd file).
>>>>>>
>>>>>
>>>>> The o_*.Rd files document more R-friendly wrappers to octave
>>>>> functions. They contain \Sexp statements that retrieve Octave help files of
>>>>> the associated function via RcppOctave o_help function:
>>>>>
>>>>> \Sexpr[results=rd,stage=render]{RcppOctave::o_help(<octave_function_name>,
>>>>> format='rd')}
>>>>>
>>>>> For packages that contain such expressions in man pages, R CMD build
>>>>> also generate the manual pdf, by installing the package in a temp directory
>>>>> and evaluating the code in all \Sexpr statements. On Windows, R CMD INSTALL
>>>>> --build also renders the man pages.
>>>>> So the issue will probably solves away when the package loads properly.
>>>>>
>>>>> For quick testing compilation and load on Windows, I run R CMD INSTALL
>>>>> directly on the package source directory with flag --no-help. To ensure a
>>>>> fresh compilation at each run I use --preclean which runs the cleanup
>>>>> script, and removes everything, including the .o, .so, .dll, .oct files:
>>>>>
>>>>> # mkdir libtest
>>>>> R --vanilla CMD INSTALL -l libtest --no-help --preclean
>>>>> pkg_src_directory
>>>>>
>>>>>
>>>>>> 3. With these changes the build gets to the point where
>>>>>>     the install process checks if the package can be
>>>>>>     loaded, and fails with:
>>>>>>
>>>>>> ** testing if installed package can be loaded
>>>>>> sh: line 1: 55395 Abort trap: 6
>>>>>> '/Library/Frameworks/R.framework/Resources/bin/R' --no-save --slave 2>&1 <
>>>>>> '/var/folders/fq/2th4vc9n1mq9cxv5nl9bmzkc0000gn/T//RtmpbjkEA7/filed5d471d0dd21'
>>>>>> R(55395) malloc: *** error for object 0x7fff7684d570: pointer being
>>>>>> freed was not allocated
>>>>>> *** set a breakpoint in malloc_error_break to debug
>>>>>> ERROR: loading failed
>>>>>> * removing ‘/Users/dsamperi/Library/R/3.0/library/RcppOctave’
>>>>>> * restoring previous
>>>>>> ‘/Users/dsamperi/Library/R/3.0/library/RcppOctave’
>>>>>>
>>>>>> 4. If I ignore this and try to run library(RcppOctave) in R I get:
>>>>>>
>>>>>> > library(RcppOctave)
>>>>>> Loading required package: Rcpp
>>>>>> Loading required package: pkgmaker
>>>>>> Loading required package: registry
>>>>>> R(55403) malloc: *** error for object 0x7fff7684d570: pointer being
>>>>>> freed was not allocated
>>>>>> *** set a breakpoint in malloc_error_break to debug
>>>>>> Abort trap: 6
>>>>>>
>>>>>> 5. Setting the breakpoint as instructed was not very helpful
>>>>>> as the malloc code does not have symbols and cannot be
>>>>>> traced.
>>>>>>
>>>>>>
>>>>> I will double check for bad allocations in the code, but will
>>>>> unfortunately be limited in my ability to debug this.
>>>>>
>>>>> Renaud
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcppoctave-user/attachments/20131010/4dcaf7de/attachment.html>