[dune-functions] SegFault in TypeErasure wrapper

Simon Praetorius simon.praetorius at tu-dresden.de
Sat Jul 25 22:02:41 CEST 2020


Dear all,

I'm facing currently a difficult to analyze segfault when implementing a 
type-erasure type based on the dune-functions wrappers in typeerasure.hh.

It is a simple design, a bit similar to a global-function - 
local-function pair, so one class with some member functions and a 
generator function for the other class. Internally some data might be 
stored sometimes. So, depending on the concrete type, either the 
polymorphic small object optimization kicks in or not. The design works 
fine for several concrete types, but in some cases when the class gets a 
bit too large, I get the segfault in the construction of the second 
class, the instance of the local-function-like class.

I was looking into this for some time now and found that in debug mode, 
it works fine and with optimization enabled, I get the segfault. It 
seems to be related to some copy-elision/return-value optimization in 
the construction.

Interestingly, a (simplified) re-implementation of the type-erasure 
framework worked fine without any segfaults. So, it must be related to a 
small difference in these implementations. Finally, I found, that when 
removing the one virtual function `target_type()` from the 
`TypeErasureBase` class it worked fine again. It even works fine, if I 
just remove the `virtual` from that function, to make it a non-virtual 
class. I think, the `virtual` is not needed for that function, so a 
removal could be a quick fix of the problem.

Is this a bug in the implementation? Is there a reason for this 
behavior? A virtual function changes the structure of the class in 
memory, an additional vtable-pointer is added, for example. Might this 
be the underlying problem? Is the small-object optimization only 
possible for non-polymorphic classes?

If we agree, that the fix above is the right way to go, I could provide 
a MR, but I'm not sure if this is the underlying source of the error.

Best regards,
Simon





More information about the dune-functions mailing list