Re[2]: [libxml++] external entities substitution - libxml++ crashes

["Igor L. Smolovski" <ismolovski stbpwr com>]

Hello Christophe,

Tuesday, October 19, 2004, 12:28:13 PM, you wrote:

CdV> Hi,

CdV> I could reproduce the problem by just setting substitute_entities to true.
CdV>  From what I can see, the problem does not come from how you use the
CdV> library.
Yes, indeed this problem can be triggered simply by setting
substitute_entities to true in ../examples/dom_entities/main.cc.
However, what I actually did was add a function which loads an XML document
with entities substitution with the help of libxml2 to libxml++ and call this
function from my own program without actually using any of libxml++
methods. I did not create any libxml++ objects at all. That very same function when placed
into a file of its own or in the same file with main() works just fine.

CdV> libxml++ use the _private field of xmlNode to store pointers to children
CdV> of xmlpp::Node.
CdV> When activating entities substitution, libxml2 seems not to keep 
CdV> _private value consistent enough for libxml++, leading to objects
CdV> deleted twice (which cause the segmentation fault you had).
Thing is I tried to load a doc by means of pure libxml2 without any
libxml++ involvement - what I did was simply place that function inside libxml++.
Just a function, not even a method of some libxml++ object or anything.
The reason I did so is this - I had come across that problem with
setting substitute_entities to true in libxml++ and started to look
for a quick solution - it soon turned out that pure libxml2 did the trick just fine
but since I was using libxml++ in my project I thought I'd integrate
it with libxml++. My attempts at integration failed and since I was at
the end of my tether I thought I'd just do a small check - add a piece
of code (which I knew worked fine on its own) to the library without really plugging it into its
internals in any way. That code doesn't rely on anything inside
libxml++, you may call it a 'foreign object' if you like. Naturally one
would think that in a situation like that there'd be no problems of
this kind and yet there is.

-- 
Best regards,
 Igor                            mailto:ismolovski stbpwr com