wlav
commented
8 months ago I remember seeing this before, but can't find it anymore. I forget what it was exactly, but something along the lines of Clang thinking a destructor was already emitted when it wasn't yet and then it segfaults. I pushed it upstream, but don't think it was ever resolved. The workaround is to add a destructor to SomeClassOwner:
struct SomeClassOwner {
~SomeClassOwner() {}
std::unique_ptr<SomeClass> obj;
void fn() { std::cout << "FUNCTION RUN" << std::endl; }
}I realize that it's not always possible to modify code that gets included, so an alternative workaround is to add a global variable in C++ before using it in python. That instantiation, too, will bring the destructor into existence (as cleanup code will be generated) so that it is later found:
struct SomeClassOwner {
std::unique_ptr<SomeClass> obj;
void fn() { std::cout << "FUNCTION RUN" << std::endl; }
};
SomeClassOwner workardound;
It seems like cppyy segfaults when there's a
unique_ptrin the class. See below for an example. The same piece of code doesn't seg fault when it'sunique_ptris replaced withshared_ptr/ stack allocated objectSomeClassOwner. (Adding a~SomeClassOwner () { }removes the segfault. )The code above segfaults with the following stack trace
The stack trace shows that the cpp object is being constructed and run correctly. Segfault error happens when object exits python frame, this is when cppyy tries to destruct the object - when cppyy tries to compile the dtor wrapper created in
make_dtor_wrapperusing cling. [see # 30 in stack trace] Looks like it is an issue with how cppyy handles destruction.