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

[Benjamin Schindler]

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
>