[xsd-users] Parsing exception with XSD hierarchy - No type information available for a type

[Benjamin Schindler]

Hi

So I just tried what I was asking - I put --export-maps in utils, and
used --imports for all the rest and that took care of the problem.

I cannot really explain the behaviour of the run I posted before, can
you boris?

Cheers
Benjamin

On 06/24/2010 10:43 AM, Benjamin Schindler wrote:
> Hi
> 
> I'm working on the same project and I just digged into this problem a
> little and it's fascinating :)
> 
> So I set a breakpoing on type-factory-map.txx:231 (register_type). I
> observed this pointers of the factory etc. We have an exe + 4 dll's.
> Static initialization happens in this order:
> 
> - utils.dll (schema without --export-maps/--import-maps)
> - datastructures.dll (--export maps)
> - dataflow.dll (contains the --export-maps)
> - server.dll (--import-maps)
> - main executable (--import-maps)
> 
> So, I looked at the this pointer of the factory, and it's rather
> fascinating (lets make it easy and use symbolic adresses):
> 
> - utils -> 0x1
> - datastructures -> 0x2
> - dataflow -> 0x3
> - server -> 0x3
> - executable -> 0x4?????
> 
> So the server correctly found the map from dataflow, but the executable
> didnd't. How can that happen?
> I double checked - the compiled schema  looks like this at the relevant
> line:
> 
> template struct __declspec (dllimport) type_factory_plate< 0, char >
> 
> We should fix our case with 2x export-maps, that's clear, but it works
> in the plugin case, so I have a hard time believing this is the problem.
> A side note: wouldn't it work if we only specified --export-maps on
> utils and used --import-maps everywhere else (even though the
> polymorphic types are in dataflow)? This would save quite a few
> map-instantiations (adding primitive types) which would reduce startup time
> 
> Thanks for your time!
> Benjamin
> 
> 
> On 06/23/2010 07:06 PM, Boris Kolpackov wrote:
>> Hi Jürgen,
>>
>> Jürgen Waser <jwaser at vrvis.at> writes:
>>
>>> In our case, it works without the --export-symbol option in the plugin  
>>> dlls because we do not include the generated plugin schema classes  
>>> outside the plugin.
>>
>> Ok, I think this could work.
>>
>>
>>> We have a theory why this could be going wrong. The executable (using  
>>> --import-maps) creates the factory map at the time of static  
>>> initialization. In this map, the TestSettings are registered. However,  
>>> at this point, base.dll has been loaded but it's static initialization  
>>> has not yet happened. Since base.dll has --export-maps specified, it  
>>> creates its own factory. This second factory is used when parsing but it  
>>> lacks the TestSettings entry. Could that be the problem?
>>
>> I don't think this is what happens. The polymorphic maps use the 
>> initialization technique that does not depend on the order of 
>> initialization of individual object files within the same
>> executable or across multiple DLLs. In the end each map is
>> represented as a pointer to the map class and is static-initialized
>> to 0. This works across multiple DLLs if this pointer is defined
>> and exported from the 'root' DLL (that's what the --export-maps
>> option does) and is imported by everybody else (--import-maps).
>> Things break if you have, for example, a DLL and an executable that
>> both have such a pointer.  
>>
>> I suggest that you double check that every single schema in your 
>> project, except for the ones in the 'root' DLL, is compiled with 
>> the --import-maps option. This problem can be caused by a single
>> "stray" schema that is not compiled with this option. Perhaps you
>> have another schema somewhere, unrelated to your plugin architecture,
>> that you compile differently?
>>
>> If none of this helps, you can try to analyze your DLLs, executables
>> and individual object files with the dumpbin[1] utility that comes
>> with Visual Studio. It has a number of options that show which
>> symbols are defined by an executable as well as which ones are
>> exported/imported from DLLs. The idea here is to make sure that
>> the map pointer mentioned above is exported from the 'root' DLL
>> and is imported by everyone else and none of the executables
>> define their own copies of these pointers.   
>>
>> [1] http://support.microsoft.com/kb/177429
>>
>> Boris
>>
>