Ticket broken by ParsingError in wiki Workflow macro

[jspurny@…]

I tried to use Workflow wiki macro to create some FSM diagram in an existing ticket (I clicked on "Modify"). The Workflow macro code was probably invalid, since it was my first one, and after saving the changes (I clicked on "Submit changes") the "Internal Error" page showed up. This error page shows whenever I view the ticket, so can't correct or remove the macro (I can delete the ticket in trac-admin, probably).

While I don't care much about not being able to use the macro, the "broken" ticket is a problem.

The error on the page:

 Trac detected an internal error:

ParsingError: File contains parsing errors: <???>
	[line  3]: u'    new_LL = initial -> inside\n'
	[line  4]: u'    new_RR = initial -> outside\n'
	[line  5]: u'    new_RL = initial -> middle\n'
	[line  7]: u'    new_from_middle_LL = middle -> inside\n'
	[line  8]: u'    new_from_middle_LL.operations = IN\n'
	[line 10]: u'    new_from_middle_RR = middle -> outside\n'
	[line 11]: u'    new_from_middle_RR.operations = OUT\n'
	[line 13]: u'    inside_to_middle_RL = inside -> middle_from_inside\n'
	[line 14]: u'    middle_from_inside_LL = middle_from_inside -> inside\n'
	[line 15]: u'    middle_from_inside_RR = middle_from_inside -> outside\n'
	[line 16]: u'    middle_from_inside_RR.operations = OUT\n'
	[line 18]: u'    outside_to_middle_RL = outside -> middle_from_outside\n'
	[line 19]: u'    middle_from_outside_RR = middle_from_outside -> outside\n'
	[line 20]: u'    middle_from_outside_LL = middle_from_outside -> inside\n'
	[line 21]: u'    middle_from_outside_LL.operations = IN\n'
	[line 23]: u'    outside_to_inside_LL = outside -> inside\n'
	[line 24]: u'    outside_to_inside_LL.operations = IN\n'
	[line 26]: u'    inside_to_outside_RR = inside -> outside\n'
	[line 27]: u'    inside_to_outside_RR.operations = OUT\n'

Python Traceback

Most recent call last:

File "/usr/lib/python2.7/dist-packages/trac/ticket/templates/ticket_box.html", line 109, in <Expression u'wiki_to_html(context, ticket.description, escape_newlines=preserve_newlines)'>
  ${wiki_to_html(context, ticket.description, escape_newlines=preserve_newlines)}
File "/usr/lib/python2.7/dist-packages/trac/wiki/formatter.py", line 1546, in format_to_html
  return HtmlFormatter(env, context, wikidom).generate(escape_newlines)
File "/usr/lib/python2.7/dist-packages/trac/wiki/formatter.py", line 1501, in generate
  escape_newlines)
File "/usr/lib/python2.7/dist-packages/trac/wiki/formatter.py", line 1244, in format
  self.handle_code_block(line, block_start_match)
File "/usr/lib/python2.7/dist-packages/trac/wiki/formatter.py", line 1134, in handle_code_block
  processed = self.code_processor.process(code_text)
File "/usr/lib/python2.7/dist-packages/trac/wiki/formatter.py", line 356, in process
  text = self.processor(text)
File "/usr/lib/python2.7/dist-packages/trac/wiki/formatter.py", line 340, in _macro_processor
  text, self.args)
File "/usr/lib/python2.7/dist-packages/trac/ticket/default_workflow.py", line 468, in expand_macro
  parser.readfp(StringIO(text))
File "/usr/lib/python2.7/ConfigParser.py", line 324, in readfp
  self._read(fp, filename)
File "/usr/lib/python2.7/ConfigParser.py", line 546, in _read
  raise e

System Information:

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0
Trac 	1.0.1
Babel 	1.3
Docutils 	0.11
Genshi 	0.7 (with speedups)
Mercurial 	2.8.2
mod_wsgi 	3.4 (WSGIProcessGroup WSGIApplicationGroup <<ANONYMIZED>>)
Pygments 	1.6
pysqlite 	2.6.0
Python 	2.7.6 (default, Mar 22 2014, 23:03:41) [GCC 4.8.2]
pytz 	2012c
setuptools 	3.3
SQLite 	3.8.2
jQuery	1.7.2

Enabled Plugins:

SimpleMultiProject 	0.0.4dev 	/usr/local/lib/python2.7/dist-packages/SimpleMultiProject-0.0.4dev-py2.7.egg
TracMercurial 	1.0.0.3dev 	/usr/local/lib/python2.7/dist-packages/TracMercurial-1.0.0.3dev-py2.7.egg

[Jun Omae]

Thanks for the reporting. Reproduced with the following.

{{{#!Workflow
  x = y
}}}

I'm going to fix it on 1.0.2.

[Jun Omae]

Proposed changes is jomae.git@t11735.

When a macro raises an exception while expanding it, Trac will handle the exception and render text of the exception. However, if it is expanded as a processor, the exception will not be caught and Trac will wrongly show its stack trace.

0.12-stable has the same issue. Should we backport [11b650f8/jomae.git] to 0.12-stable?

[Jun Omae]

I think we should apply the changes to 0.12-stable.

[Christian Boos]

Right, that's a kind of DOS, it makes sense to fix it on 0.12-stable as well.

[Jun Omae]

Thanks for response. Committed to 0.12-stable in [13104] and merged to 1.0-stable and trunk in [13105-10107].