[mythtv] Problems with dynamic_cast

Mark Spieth mark at digivation.com.au
Thu Jan 30 04:45:26 UTC 2020


On 30/01/2020 2:18 am, David Engel wrote:
> On Thu, Jan 30, 2020 at 12:05:25AM +1100, Mark Spieth wrote:
>> On 1/29/2020 3:02 PM, Mark Spieth wrote:
>>> On 29/01/2020 1:35 pm, David Engel wrote:
>>>> On Wed, Jan 29, 2020 at 11:24:45AM +1100, Mark Spieth wrote:
>>>>> I have another instrumented test if someone can test it.
>>>>> Otherwise it will
>>>>> have to wait for approx 7 hours when I get home.
>>>>>
>>>>> http://digivation.com.au/debian/mythfrontend-20200129-arm64-v31-Pre-1828-g4b2272287a-dirty.apk
>>>>>
>>>>>
>>>>> use adb logcat | tee x.log
>>>>>
>>>>> The test is
>>>>>
>>>>> settings -> video -> playback -> change profile to something else
>>>>>
>>>>> Then email me with the last bit of the log where it mentions dce
>>>>> especially.
>>>> 01-28 20:30:23.656 32532 32555 I mfe     :
>>>> mythdialogbox.cpp:452:SendEvent  post dce:140920670464
>>>> dce_e:P21DialogCompletionEvent:140813528616 ev:140920670464
>>>> ev_e:P6QEvent:140813528641
>>>> 01-28 20:30:23.656 32532 32555 I mfe     :
>>>> standardsettings.cpp:815:customEvent  evtype:65518
>>>> 01-28 20:30:23.656 32532 32555 I mfe     :
>>>> standardsettings.cpp:832:customEvent  dce:0 e:P6QEvent:140818516747
>>>> qe:P6QEvent:140818516747 d2:P21DialogCompletionEvent:140818516722
>>>>
>>>> I'll send you the whole log privately if you want it.
>>>>
>>> Well thats interesting. sender newed DialogCompletionEvent type is
>>> different from one in libmyth. no wonder it doesnt work.
>>>
>>> now to try -rdynamic as a SO post suggests.
>> Found it!
>>
>> The key is
>>
>> https://android.googlesource.com/platform/ndk/+/master/docs/user/common_problems.md#rtti_exceptions-not-working-across-library-boundaries
>>
>> I added a virtual destructor to DialogCompletionEvent and that one works.
>> Now to do it for the rest that use dynamic_cast. Ive left -rdynamic in place
>> as others have said its necessary.
>>
>> It works as it forces a vtable to exist only in the so that has the virtual
>> function defined. Every subclass needs at least one defined non inline
>> virtual function.
> I poked around last night but didn't get anywhere.  Glad you found it.
> Good work.  My big question is why doesn't the compiler complain in
> such cases?  Or does it and we just missed it?
>
> David

Others have asked the same question.

How can it complain when it doesn't know that there is a shared object 
at compile time vs link time?

Where is the master/source of truth vtable/typeinfo when it can be 
optimized out?

clang must do more optimisation than g++ and this is why we are seeing 
it now.

Has anyone ever compiled the linux version with clang? I expect similar 
issues.

We could try different linkers (BFD or gold vs llvm-ld) but if the 
compiler does not put in appropriate symbols that may not be possible. 
Because all virtual functions are in the header there is no single 
source of truth at compile time (though there is at link time). A job 
for smarter people than me.

I have pushed the final change to expose locked vtables in affected 
classes. There should not be any more. Some already had object locked 
virtual functions so they did not need to be updated.

Mark



More information about the mythtv-dev mailing list