[xsd-users] Bug in ACE CDR deserialization

Boris Kolpackov boris at codesynthesis.com
Wed Jul 25 06:26:55 EDT 2007


Hi James,

James Frullo <jamesfrullo at gmail.com> writes:

> I built ACE by linking to the Multi-threaded Debug DLL version
> of the CRT, but I built the sample using the plain Multi-threaded Debug
> version.  This brought out a non-obvious bug in the implementation of the
> following function:
> inline istream<ACE_InputCDR>& operator>> (istream<ACE_InputCDR>& s,
> std::basic_string<char>& x)

This is really a bug in the Windows DLL model, not in the above
function. I don't think it will be fixed any type soon, though ;-).


> The problem with this is that calling read_string() gives you memory
> allocated by ACE.  But auto_array is going to deallocate that memory by
> calling delete[].  Since ACE is compiled and linked separately, it is
> incorrect to assume that this will work.  In fact, it does not work.  It
> crashes because using the build configurations I mentioned above.  The
> correct code would be something like:
>
>        ACE_CDR::Char* r;
>
>        if (!s.impl ().read_string (r))
>          throw ace_cdr_stream_extraction ();
>
>        try {x = r} catch(...){ACE::strdelete(r);throw;}
>        ACE::strdelete(r);
>
>        return s;
>
> Of course, this is ugly. A nicer way would be to have an ace_auto_str()
> class (or whatever).

It is not just ugly, it simply won't work because there is no strdelete
or anything similar that I am aware of. ACE CDR code uses new[] to
allocate the memory and delete[] to free it. There is no wrapper to
call "ACE's version of delete[]". The only way to make it work (aside
from linking your application with the DLL version of the runtime) is
to handle string serialization ourselves which would require copying
quite a bit of implementation details from ACE to the above function.
This is a bad idea in itself because that code can change in the future.
Furthermore, the code that handles wchar_t serialization (that would
need to be copied as well) is really messy and has various branches
for different versions of GIOP. I really don't think it is a good idea
to drag it into XSD.

I will think some more about other possible ways to fix this. If you
have any ideas, let me know. And thanks for reporting this!


-boris




More information about the xsd-users mailing list