On 05/07/2021 2:50 p.m., Bill Dunlap wrote:
I think the stack trace is omitting the initial underscore in the symbol
name:
> c++filt
_ZN4Rcpp8CppClassC1EPNS_6ModuleEPNS_10class_BaseERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
Rcpp::CppClass::CppClass(Rcpp::Module*, Rcpp::class_Base*,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&)
Thanks. It doesn't work for me with the leading underscore, but I'm
using a clang based compiler, not gcc, so maybe that explains it. (I've
tried most of the --format= options, without success.)
Duncan
-Bill
On Mon, Jul 5, 2021 at 11:01 AM Duncan Murdoch <murdoch.dun...@gmail.com
<mailto:murdoch.dun...@gmail.com>> wrote:
On 05/07/2021 10:32 a.m., Ben Bolker wrote:
> I'm running into trouble checking a new release of the
'broom.mixed'
> package
<https://cran.r-project.org/web/packages/broom.mixed/index.html
<https://cran.r-project.org/web/packages/broom.mixed/index.html>>
> on win-builder. I think it is some kind of rstan problem.
>
> The broom.mixed package loads the brms package, and loads several
> pre-computed objects from the brms package; I don't think it actually
> tries to run anything of the functions from brms during the check
process.
>
> At several points during checking (see
> <https://win-builder.r-project.org/LsDDMqpnX52n/00check.log
<https://win-builder.r-project.org/LsDDMqpnX52n/00check.log>>), I get
> voluminous "C stack trace" outputs: once when "Checking
dependencies in
> R code", once when calling require(brms) as part of an example, once
> when running the tests (not easy to determine the precise
location, and
> once when building the vignettes).
>
> The trace starts like this:
>
> ==== C stack trace ===============================
>
> SETCAR [0x0x6c838a90+32]
>
ZN4Rcpp8CppClassC1EPNS_6ModuleEPNS_10class_BaseERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE [0x0x6ac093ff+1151]
> ZN4Rcpp6Module12classes_infoEv [0x0x6ac07467+327]
> Z20Module__classes_infoP7SEXPREC [0x0x6abe1c4a+74]
> Rf_NewFrameConfirm [0x0x6c7a7d18+33960]
> R_initAssignSymbols [0x0x6c7f3259+53849]
> Rf_eval [0x0x6c7fcd31+369]
> ...
>
> and goes on for a while.
>
> R CMD check runs fine on Linux with recent r-devel.
>
> Has anyone seen this? Other than scrubbing all references to
brms
> and rstan (a second try with one of the brms references avoided
instead
> runs into trouble when loading rstan ...), I don't see what I can
do ...
>
> <https://win-builder.r-project.org/YArr24tuYZ8G/00check.log
<https://win-builder.r-project.org/YArr24tuYZ8G/00check.log>>
>
What error do you get before the stack trace?
The Z... names look like C++ entry points to overloaded functions or
methods. There's a command line function (c++filt) that will usually
turn those into their original readable form. It's not working for me
on the names you've got; maybe because I'm on a Mac, and that was
compiled on Windows. Perhaps someone else knows how to demangle those
names?
Duncan Murdoch
______________________________________________
R-package-devel@r-project.org <mailto:R-package-devel@r-project.org>
mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
