← Back to team overview

dolfin team mailing list archive

Re: Buildbot fails a lot with "Error: Unable to dolfin::plot"

 

Well...

After chasing this for some hours I found why the shared libraries screw
up the dynamic_cast. The full type info of the MeshFunction<whatever> is
not available in the compiled SWIG module of _io.so, where the plot
command is called.

To remedy this we need to share all type informations when the libraries
are loaded. This can be controlled by setting the flag RTLD_GLOBAL to
the loader. In python this is done by using:

  sys.setdlopenflags

Because previously it was only Python2.6 buildbots that had this
problem, so one could think that this flag is set by default in 2.7, but
it is not. So still not clue why it failed on two buildbots.

Anyhow, it now works, and we should be able to still use dynamic_cast.

Johan

On 11/29/2012 07:19 PM, Johan Hake wrote:
> On 11/29/2012 02:42 PM, Joachim Berdal Haga wrote:
>> Ok, no easy fix for this one then.
> 
> It does not look like it...
> 
> It is the runtime type info (RTTI) that is not well defined across
> shared libraries, which we have with the SWIG interface.
> 
> From a random web page:
> 
> There is no surprise here. Even for normal non-templated classes, you
> should never expect the RTTI to work across shared-library boundaries.
> For some compilers, on some OSes, with some compiler or linker options,
> it might work, but in general, it will not, and is not required to
> (explicitly left unspecified in the Standard). And even if you make it
> work, it will be unsustainable in the long-run.
> 
> 
> This does not sounds encouraging... I wonder if it is the compiler
> version, which prevents it from working on the two buildbots.
> 
> Also there might be ways to get around using RTTI. For example:
> 
>  http://ciaranm.wordpress.com/2010/05/24/runtime-type-checking-in-c-without-rtti
> 
> If I did not miss something he assign an enumerate to each derived class
> and use that to check for correct type. That sounds tedious, but maybe
> not that bad considering we only need to check the Variable hierarchy?
> 
> Mvh
> 
> Johan
> 
>> I'm still inclined to suspect the swig type info, because it's the
>> only thing I can think of that can plausibly explain the symptoms. The
>> pointer (as seen in VTKPlotter) would be NULL, or perhaps
>> reinterpret_cast-ed to something else. And it wouldn't be the first
>> time swig was confused by templated types. Why it fails only on these
>> machines is a mystery though.
>>
>> -j.
>>
>> On 29 November 2012 13:58, Johan Hake <hake.dev@xxxxxxxxx> wrote:
>>> It has to do with a failing
>>>
>>> boost::dynamic_pointer_cast<const T >(var);
>>>
>>> where T is a shared_ptr type. See line 92 in VTKPlotter.cpp.
>>>
>>> This is the same problem we have with the uBLAS type converter we have
>>> for a failing la unit test:
>>>
>>>   test/unit/la/python/test.py
>>>
>>> I challenge anyone with enough C++ foo to take this one head on!
>>>
>>> Johan
>>>
>>> On 11/29/2012 01:21 PM, Martin Sandve Alnæs wrote:
>>>> Can someone who knows what the proper fix handle this? It would be nice
>>>> to have a green buildbot again...
>>>>
>>>>
>>>>
>>>> ***
>>>> -------------------------------------------------------------------------
>>>> *** DOLFIN encountered an error. If you are not able to resolve this issue
>>>> *** using the information listed below, you can ask for help at
>>>> ***
>>>> ***     https://answers.launchpad.net/dolfin
>>>> ***
>>>> *** Remember to include the error message listed below and, if possible,
>>>> *** include a *minimal* running example to reproduce the error.
>>>> ***
>>>> ***
>>>> -------------------------------------------------------------------------
>>>> *** Error:   Unable to dolfin::plot.
>>>> *** Reason:  Object type not supported for plotting.
>>>> *** Where:   This error was encountered inside plot object.
>>>> *** Process: 2
>>>> ***
>>>> -------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~dolfin
>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dolfin
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dolfin
>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dolfin
>>> More help   : https://help.launchpad.net/ListHelp
> 



Follow ups

References