Hi,
On Fri, Nov 23, 2012 at 11:12:01AM +0000, Philip Martin wrote:
> net_robber <net_robber_at_timectrl.net> writes:
>
> > XML: char-data (274) returns 0
> > XML: start-element (274, {svn:, close-file}) => 279
> > XML: end-element (279, {svn:, close-file})
> > XML: char-data (274) returns 0
> > XML: XML_Parse returned 0
> > XML: Parse error: XML parse error at line 384: not well-formed (invalid token)
>
> Do a network trace to identify the invalid XML:
>
> http://subversion.apache.org/docs/community-guide/debugging.html#net-trace
In this case I don't think that's necessary.
The first line of his log showed the last part of the XML data
(I assume he obviously didn't want to post his entire visible data content).
I happen to have written an explanation for such cases (however not
published before yet):
=====
XML: Parse error: XML parse error at line 41: not well-formed (invalid token)
If you happen to experience XML parse errors in your Subversion debug output (e.g. "invalid token"), then do the following:
either you're lucky enough to have a sufficiently modern client which does properly log the token involved, or you have an older one which inexcusably doesn't. In that case don't even bother trying to match up the rather confusing XML line number as displayed by that Subversion error. Rather, put both the corresponding response data and the subsequent corresponding XML parser log (those should have a *matching* byte count, e.g. "7340 bytes received")
side by side in two editors and go through them line by line
(or rather: tag type by tag type!) until you should be able
to find the problematic line at the end of the XML parser log.
Some potential things to watch out for are:
- missing space (' ') between XML attributes (--> protocol error)
=====
The missing spaces was what had happened in my case.
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
Received on 2012-11-25 14:17:15 CET