[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSXML test failures
Re: GSXML test failures
Thu, 14 Mar 2002 12:30:22 +0000 (GMT)
> I ran the regression test on gnustep-base and saw that there are a bunch
> of failures and some odd log message in the GSXML tests.
I believe GSXML memory management (for the code managing the full parse
tree) is broken without hope, and the GSXML tests just explain some issues
The problem is with freeing the memory used by libxml2. libxml2 has no
memory counting for nodes, namespaces etc and frees all nodes and
namespaces in a document when the document is freed. The current API for
GSXML instead assumes the you can have GSXML nodes and namespaces
standalone, and then you can add/remove them from documents and or connect
nodes and namespaces freely.
That will never work, because as soon as the backend document is freed,
all backend nodes belonging to it are freed - leaving all Objective-C
wrapper objects for those nodes with invalid references inside. The GSXML
API would like the lifetime of the nodes to extend over that of the
document (since GSXMLDocument and GSXMLNode are different objects, and you
can RETAIN a GSXMLNode, but RELEASE the owning GSXMLDocument, and
obviously the GSXMLNode - having been retained - should remain usable),
but that can't be achieved (unless - my solution - all GSXMLNodes
belonging to a document retain the GSXMLDocument ... that requires
modifications in the API to support the fact thta GSXMLNodes contain a
pointer to their GSXMLDocument, and to keep the pointer updated).
When it comes to namespaces, it's even more complicated, since currently
namespaces are not tidied to documents in any way ... in the backend the
namespaces are released when the owning node is released ... that is
completely unaccounted in the code now.
Anyway - I came to the conclusion that the only way to fix is it is to
change the API of the GSXMLDocument, GSXMLNode and GSXMLNamespace classes
enforcing some much more strict relationships between the different
objects - each node *must* belong to a document (and retains the document,
and you can't build a node without a document); each namespace *must*
belong to a node (and retains the node, and you can't build a namespace
without a node); you can't unlink a node from a document, you can at most
move the node from one place in the document to another place, or destroy
the node completely.
This only for the GSXML tree stuff - the GSXML SAX parser is fine instead
and seems to be working fine, I'm pretty happy with it (even if the API
could be improved).
I suppose the nice right way to go would be to rewrite the GSXML tree
stuff on top of the GSXML SAX handler ... in practice, rewriting part of
libxml2 in Objective-C. That would be nice and would free us from libxml2
backend memory problems ... but it's a lot of work and it would likely
require a lot of effort to be made to work.
I'm not sure what other developers (Richard, you, etc) think of this
matter :-) and I don't want to rewrite a lot of code just for the sake of
it ... I'm so happy with the GSXML SAX parser I think I will always use
that for parsing everything (and generate XML manually, even if for
generating XML some functionality more in the GSXML would be helpful, such
as methods XML-escaping strings for usage inside attributes or contents
etc), so I told Richard, but I've not rewritten anything.
If you have opinions on the matter, let me know. If you think you can fix
the GSXML memory management, please do. I'm pretty sure whatever fix you
do, I can build a test case which breaks/crashes it :-) - unless you
change the API - but some more wide agreement is needed to change the API.