CRITICAL: not well-formed (invalid token): line 3, column 28

890 views
Skip to first unread message

Richard Parks

unread,
Apr 7, 2015, 2:18:43 PM4/7/15
to revie...@googlegroups.com
Hi, we're running two separate linux clusters, both with different versions of rbt, svn, python and linux but both show the same post error:

CRITICAL: not well-formed (invalid token): line 3, column 28

This error comes up on any rbt diff or post, and is not a problem with the svn repo as I can diff and post fine locally.

The first cluster:
>>> RBTools 0.7.2
>>> Python 2.7.7 (default, Feb 10 2015, 10:28:27)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)]
>>> Running on Linux-2.6.18-164.15.1.el5-x86_64-with-redhat-5.4-Final
Subversion command-line client, version 1.7.5.


The second cluster:
>>> RBTools 0.7.1
>>> Python 2.6.6 (r266:84292, Jan 22 2014, 09:42:36)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]
>>> Running on Linux-2.6.32-431.29.2.el6.x86_64-x86_64-with-centos-6.5-Final
Subversion command-line client, version 1.7.16.



running diff in debug:
rbt diff --debug 12192 12208
>>> RBTools 0.7.2
>>> Python 2.7.7 (default, Feb 10 2015, 10:28:27)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)]
>>> Running on Linux-2.6.18-164.15.1.el5-x86_64-with-redhat-5.4-Final
>>> Home = /home/myusername
>>> Current directory = /projects/fw/myusername/myprojectbranch
>>> Checking for a Subversion repository...
>>> Running: svn info --non-interactive
>>> Running: diff --version
>>> Running: svn --version -q
>>> repository info: Path: http://mycompanysvnrepo, Base path: /branches/development/myprojectbranch, Supports changesets: False
>>> Making HTTP GET request to http://reviewboard.mycompany
>>> Running: svn log -r 12192 -l 1 --xml
Password for 'myusername':
Traceback (most recent call last):
 
File "/usr/local/bin/rbt", line 8, in <module>
    load_entry_point
('RBTools==0.7.2', 'console_scripts', 'rbt')()
 
File "/usr/local/lib/python2.7/site-packages/RBTools-0.7.2-py2.7.egg/rbtools/commands/main.py", line 133, in main
    command
.run_from_argv([RB_MAIN, command_name] + args)
 
File "/usr/local/lib/python2.7/site-packages/RBTools-0.7.2-py2.7.egg/rbtools/commands/__init__.py", line 555, in run_from_argv
    exit_code
= self.main(*args) or 0
 
File "/usr/local/lib/python2.7/site-packages/RBTools-0.7.2-py2.7.egg/rbtools/commands/diff.py", line 47, in main
    revisions
= tool.parse_revision_spec(args)
 
File "/usr/local/lib/python2.7/site-packages/RBTools-0.7.2-py2.7.egg/rbtools/clients/svn.py", line 166, in parse_revision_spec
   
'base': self._convert_symbolic_revision(revisions[0]),
 
File "/usr/local/lib/python2.7/site-packages/RBTools-0.7.2-py2.7.egg/rbtools/clients/svn.py", line 183, in _convert_symbolic_revision
    root
= ElementTree.fromstring(log)
 
File "/usr/local/lib/python2.7/xml/etree/ElementTree.py", line 1300, in XML
    parser
.feed(text)
 
File "/usr/local/lib/python2.7/xml/etree/ElementTree.py", line 1642, in feed
   
self._raiseerror(v)
 
File "/usr/local/lib/python2.7/xml/etree/ElementTree.py", line 1506, in _raiseerror
   
raise err
xml
.etree.ElementTree.ParseError: not well-formed (invalid token): line 3, column 28

To me this looks like a python error but both clusters show exactly the same error and are running different version of python. Incidentally when I post locally and it works, I'm running python 2.7.9.

Has anyone else encountered this error? Any help greatly appreciated! Thanks in advance.

Griffin Myers

unread,
Apr 8, 2015, 10:21:41 PM4/8/15
to revie...@googlegroups.com
Can you share the output of:


svn log -r 12192 -l 1 --xml

The less sanitized the better, although I guess line 3 will be the most critical.  I suspect some sort of encoding issue, but I don't know why this is system dependent.  Perhaps something to do with locales?

Richard Parks

unread,
Apr 9, 2015, 4:22:23 AM4/9/15
to revie...@googlegroups.com
Hi Griffin,

Thanks for your help on this as well, here's the svn log:

svn log -r 12192 -l 1 --xml
<?xml version="1.0" encoding="UTF-8"?>
<log>
Authentication realm: <http://mycompanysvnrepo:80> Subversion repositories (mydepartment)
Password for 'myusername':
<logentry
   revision
="12192">
<author>myusername</author>
<date>2015-04-02T13:17:52.412260Z</
date>
<msg>My description of what I'm working on here</msg>
</logentry>
</log>



Griffin Myers

unread,
Apr 9, 2015, 9:51:29 PM4/9/15
to revie...@googlegroups.com
Hi Richard,

Am I correct that "rbt diff" is prompting you for your svn password?  If so, then there is likely a bug in here.  Do you have any better luck if you try:

rbt diff --debug --svn-password <your password> 12192 12208

You might also need --svn-username, but it looks like it already has the correct username for you.

Thanks,
Griffin

Richard Parks

unread,
Apr 10, 2015, 5:15:13 AM4/10/15
to revie...@googlegroups.com
Hi Griffin,

You're absolutely spot on, it was prompting for my svn password and then failing, if I rbt diff or post and give it --svn-username it works fine.

It would be good to find out if this is a bug with RBTools or if it is a problem with the way we run our linux cluster and/or svn repo here.

Thanks so much Griffin.

Barret Rennie

unread,
Apr 10, 2015, 8:07:39 PM4/10/15
to revie...@googlegroups.com
Hey Richard,

Looking at your log, character 28 is a forward slash (the one in the <http://...> bit). The password prompt is getting mixed in with the log entry and is trying to be parsed as XML, resulting in the exception you were running into. I’ll have a look to see if this stuff can be excluded when we parse log so this situation can be avoided.

Regards,
Barret
--
Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups "reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Griffin Myers

unread,
Apr 12, 2015, 8:56:54 PM4/12/15
to revie...@googlegroups.com
Richard,

Barret already gave you the technical explanation -- and what I think amounts to a bug in RBTools.  I highly doubt that this is indicative of any problem on your end with respect to your cluster or repo configuration.  If I had too guess, your cluster is a shared resource and you have it configured either globally or on a per-user basis not to store SVN passwords, as by default these are stored as plain text under Linux.  I suspect you are saving your password on your local machine which is why the post operation succeeded there.

Griffin

Richard Parks

unread,
Apr 13, 2015, 9:54:56 AM4/13/15
to revie...@googlegroups.com
Thanks Barret,
Yes if the password could be parsed differently that would be great. Whilst using --svn-password works well it is indeed on a shared resource and so there is, at least for a short while, my svn password floating around in plaintext.
Please let me know if you post a fix for this and I will happily try it out.

Richard Parks

unread,
Apr 13, 2015, 9:58:17 AM4/13/15
to revie...@googlegroups.com
Hi Griffin,
Yes you're correct on all counts, both of our clusters are shared resources and are configured not to store svn passwords. My local machine on the other hand is pretty secure and so does save my svn password.
It's good to fully understand the reasons behind an error so thanks for all your help.

Best regards,
Richard

Barret Rennie

unread,
Apr 15, 2015, 3:08:49 PM4/15/15
to revie...@googlegroups.com
Hello again,

Our fix for this issue has landed in both the release-0.7.x and master branches of RBTools; it will be in RBTool 0.7.3 and all future releases.

We now force svn log to run non interactively and if there is an authentication error with the remote repository, a helpful error message is printed out that tells the user how to authenticate with command line flags (instead of the awful and vague error message you reported). We’ve also added a --svn-prompt-password option to RBTools that will prompt you for your SVN password so that it isn’t visible in your console or in your history.

I hope these improvements suit your needs. Thanks again for reporting this issue.

Regards,
Barret Rennie
Reply all
Reply to author
Forward
0 new messages