[xsd-users] Re: Access Violation when deleting objects

[Boris Kolpackov]

Hi Bruno,

In the future please send technical questions like these to the
xsd-users mailing list (which I've CC'ed) instead of to me directly.
This way a) other developers who may have experienced a similar
problem can provide you with a solution b) questions and answers
will be archived and available to others with similar problems.

bruno.marotta at fortis.com <bruno.marotta at fortis.com> writes:


> I am still playing with your XSD classes. I think that I don't have
> to tell that I found them great.

Thanks, I am glad you like it.


> Not quite so easy to use, but when you get to known it flows smoothly.

Is it difficult to use before you've read the Getting Started Guide[1] or
after?

[1] http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/


> The thing is, now I am separting the interfaces on a dll, so I used
> the export option from the xsd generation. But, when some classes
> are freed, it throws an access violation. As these are hard to debug,
> I've starting decouping until I really isolated the problem. Basically
> I have one class like this:
>
> class __declspec(dllexport) ObligorID: public ::xml_schema::string

Do you really have __declspec(dllexport) there or is it some CPP macro
that changes from __declspec(dllexport) to __declspec(dllimport)?


> {
>   public:
>   // Constructors.
>   //
>   ObligorID ();
>
>   ObligorID (const ::xml_schema::string&);
>
>   ObligorID (const ::xercesc::DOMElement& e,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   ObligorID (const ::xercesc::DOMAttr& a,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   ObligorID (const ::std::string& s,
>              const ::xercesc::DOMElement* e,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   ObligorID (const ObligorID& x,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   virtual ObligorID*
>   _clone (::xml_schema::flags f = 0,
>           ::xml_schema::type* c = 0) const;
> };
>
> Which is fairly simple. On the executable where I call the dll, if I
> do a simple:
>
> 	ObligorID* obl = new ObligorID("131 xxxxxxxxxxxxxwxxxx");
> 	delete obl;
>
> As the first entries of the main, I get an exception on the delete.
> Do you have any idea where does this came from?

That's very strange. The usual suspect would be the cross-DLL memory
allocation/deallocation but here you create and delete the object in
main() so this can't be it. Just to confirm, can you change the
generated object code type in both your application and DLL to use
the DLL runtime and see if there is any change?

You may also want to step into the "delete obl" statement in the
debugger and see what's going on and where it crashes. Or you can
send me a small example that reproduces this problem and I will
take a look.


> Also, I am wondering why on the getters and setters of the classes
> sometimes you can simply pass a string (for the dates, for instance)
> and sometimes you mas pass an instantiated object from a string. Example:
>
> asset.MaturityDate("2005-01-01"); // Nice way of doing it
> asset.AssumedRecoveryLookup(AssumedRecoveryLookup("N")); // Why can't I just pass the "N"?

C++ does not allow chains of implicit conversions. In other words, if
you have class A that has an (implicit) constructor from const char*
and class B that has an (implicit) constructor from A and you have a
function f() with argument of type B, then you cannot pass "foo" to
it because that would require a chain of conversions:
const char*-> A -> B

In the above example, MaturityDate() has an argument which can be
implicitly constructed from a string literal while AssumedRecoveryLookup()
does not. Can you tell me what the AssumedRecoveryLookup schema type
looks like?

Boris