[serialization] VC7.1 STL facet deletion bug when overloading operators new/delete
Hello! I'm having an assertion failure when working with xml_oarchive. The problem is that in xdebug library header, _NEW_CRT is defined as another operator new. All standard facets are created using _NEW_CRT. But my application overload operators new/delete/new[]/delete[], So when _DELETE_CRT is called to delete the facet created in basic_text_oprimitive.ipp : 90 The code is: archive_locale.reset( add_facet( std::locale::classic(), new codecvt_null<BOOST_DEDUCED_TYPENAME OStream::char_type> ) It raises an assertion failure, since it wasnt used the same operator for creating and deleting the object. This assertion only occurs when _DEBUG is defined. The workaround I used was to replace new for _NEW_CRT, but it will certainly only work for my STL. This "different operator new" is only used for facets in the VC7.1 STL. The boost I'm using is the one in cvs (downloaded yesterday). Thanks in advance, -- Felipe Magno de Almeida
I sort of understand the problem - are you asking us to do anything specific? It seems you've got it straightened out for your particular case. Here are some other ideas. a) You could open the xml_?archive with the no_codecvt flag. This will prevent the library from changing the code_convert facet. Of course if you do this you'll probably want to change the code_cvt facet of the text streams you use in your application. But given that its from within your app, you can use your own new overload so this problem can be addressed without changing the your STL library headers b) You could compile the whole boost library using your debug new. Then everything would be consistent. Good Luck with this. Robert Ramey Felipe Magno de Almeida wrote:
Hello!
I'm having an assertion failure when working with xml_oarchive. The problem is that in xdebug library header, _NEW_CRT is defined as another operator new. All standard facets are created using _NEW_CRT. But my application overload operators new/delete/new[]/delete[], So when _DELETE_CRT is called to delete the facet created in basic_text_oprimitive.ipp : 90 The code is:
archive_locale.reset( add_facet( std::locale::classic(), new codecvt_null<BOOST_DEDUCED_TYPENAME OStream::char_type> )
It raises an assertion failure, since it wasnt used the same operator for creating and deleting the object. This assertion only occurs when _DEBUG is defined. The workaround I used was to replace new for _NEW_CRT, but it will certainly only work for my STL. This "different operator new" is only used for facets in the VC7.1 STL.
The boost I'm using is the one in cvs (downloaded yesterday).
Thanks in advance,
On 1/15/06, Robert Ramey <ramey@rrsd.com> wrote:
I sort of understand the problem - are you asking us to do anything specific?
I think it could be added a workaround. When detected VC7.1 and its STL, it could use _NEW_CRT operator instead of the general new.
It seems you've got it straightened out for your particular case. Here are some other ideas.
a) You could open the xml_?archive with the no_codecvt flag. This will prevent the library from changing the code_convert facet. Of course if you do this you'll probably want to change the code_cvt facet of the text streams you use in your application. But given that its from within your app, you can use your own new overload so this problem can be addressed without changing the your STL library headers
The problem is that the locale doesnt use the overloaded operator delete, but a function called: std::_DebugHeapDelete, so the facet should be created using _NEW_CRT. And it will probably be hard to detect if more facets are being used without a proper workaround in boost, leaving not detected bugs. Although I'm already looking forward to a compiler upgrade. But I'm still concerned about other VC7.1 users of serialization library.
b) You could compile the whole boost library using your debug new. Then everything would be consistent. Good Luck with this.
That's what I've done for now, but I think more people overloading operators new/delete and using serialization library will have a hard time finding this STL bugs again. IMHO, a workaround in the serialization library (or a more general create_facet, which would embed the workaround in detail namespace, for use in more libraries in boost) would be better for serialization users.
Robert Ramey
[snip] Thanks for you attention. -- Felipe Magno de Almeida
participants (1)
-
Felipe Magno de Almeida -
Robert Ramey