MantisBT - CDash
View Issue Details
0010964CDash[CMake] CTestpublic2010-07-08 16:032011-01-04 11:56
Ryan Pavlik 
Zach Mullen 
normalminoralways
resolvedfixed 
 
1.9 
0010964: CDash 1.6.4 - test output "crashes" the log page
I have a test process that runs under CTest and submits to my cdash 1.6.4 dashboard. I'm pretty sure that the issue is because it inserts codes to change the text color in the terminal. In any case, attempting to load the view-test-log pages in CDash (url: CDash/testDetails.php?test=3600&build=1293 ) just presents a number of errors, all identical:
Warning: DOMDocument::loadXML() [domdocument.loadxml]: PCDATA invalid Char value 27 in Entity, line: 39 in /home/rpavlik/web/CDash/cdash/common.php on line 39

The actual log itself is never shown. Thinking that the logs should be cleaned/escaped at some level - not sure if that's a CTest issue or a CDash issue (hoping it's CDash so I can update once for all...). Please let me know what files (test logs, etc) you need to debug this issue if I have not provided them.
No tags attached.
log LastTest_20100630-0119.log (41,766) 2010-07-08 16:03
https://public.kitware.com/Bug/file/3232/LastTest_20100630-0119.log
xml Test.xml (21,915) 2010-07-08 16:03
https://public.kitware.com/Bug/file/3233/Test.xml
html testDetails.php.html (16,833) 2010-07-08 17:01
https://public.kitware.com/Bug/file/3234/testDetails.php.html
Issue History
2010-07-08 16:03Ryan PavlikNew Issue
2010-07-08 16:03Ryan PavlikFile Added: LastTest_20100630-0119.log
2010-07-08 16:03Ryan PavlikFile Added: Test.xml
2010-07-08 17:01Ryan PavlikFile Added: testDetails.php.html
2010-12-15 11:02Brad KingNote Added: 0024157
2010-12-15 12:28David ColeProjectCMake => CDash
2010-12-15 12:28David ColeAssigned To => Zach Mullen
2010-12-15 12:28David ColeStatusnew => assigned
2010-12-15 12:29David ColeNote Added: 0024177
2011-01-04 10:53Zach MullenNote Added: 0024391
2011-01-04 10:53Zach MullenStatusassigned => acknowledged
2011-01-04 11:03Zach MullenNote Added: 0024392
2011-01-04 11:15David ColeNote Added: 0024394
2011-01-04 11:16David ColeNote Edited: 0024394bug_revision_view_page.php?bugnote_id=24394#r71
2011-01-04 11:16David ColeNote Edited: 0024394bug_revision_view_page.php?bugnote_id=24394#r72
2011-01-04 11:16David ColeNote Edited: 0024394bug_revision_view_page.php?bugnote_id=24394#r73
2011-01-04 11:43Zach MullenNote Added: 0024395
2011-01-04 11:56Zach MullenNote Added: 0024396
2011-01-04 11:56Zach MullenStatusacknowledged => resolved
2011-01-04 11:56Zach MullenFixed in Version => 1.9
2011-01-04 11:56Zach MullenResolutionopen => fixed

Notes
(0024157)
Brad King   
2010-12-15 11:02   
There are 2 forms of Test.xml from CTest: uncompressed and compressed.

(1) The uncompressed format shows the test output in human-readable form and always contains valid UTF-8 encoded XML since this commit:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4beefeb [^]

which was merged for CMake 2.8.1 (back in CVS-hosted days so it is a different commit) here:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dc1d2189#patch249 [^]

Invalid encoding in test output is replaced with some human-readable placeholders that describe the error. This transformation is necessary to submit valid Test.xml files with bad test output while keeping the files human-readable (e.g. not base64 encoded).

(2) The compressed format is not human readable anyway so we just use base64 encoding to generate valid Test.xml files regardless of test output. When CDash receives such files and decompresses the output it is then responsible for handling what it gets.

This is a CDash issue, not a CTest issue. CDash needs to check the validity of the UTF-8 encoding in the test output after uncompressing it and store only valid UTF-8 encoded data in its database.
(0024177)
David Cole   
2010-12-15 12:29   
Moved to "CDash" and assigned to Zach after reading Brad's note ( http://public.kitware.com/Bug/view.php?id=10964#c24157 [^] )
(0024391)
Zach Mullen   
2011-01-04 10:53   
Going to fix this in CDash trunk.
(0024392)
Zach Mullen   
2011-01-04 11:03   
What behavior would be preferable for handling non printed characters: replace them with a placeholder like a question mark, or just remove them altogether?
(0024394)
David Cole   
2011-01-04 11:15   
(edited on: 2011-01-04 11:16)
Replace them with an escaped/encoded representation such that a human reader can tell what the original character was...

As in "%20" == a space character in a URL, or "&# 32;" in escaped HTML-ese, something along these lines would be the way to print a non-printing character in test output shown in a CDash web page.

See, for example, the set of HTML 4 Special Characters listed here:
http://tntluoma.com/sidebars/codes/ [^]

I don't think it matters exactly how we represent these as long as we make it "human interpretable" if not necessarily easily readable. If you can find a pattern like this on other web sites that you like, mimic it.

(0024395)
Zach Mullen   
2011-01-04 11:43   
Sounds good. Any preference between these two styles:

&0x1b;

vs.

&27;

?
(0024396)
Zach Mullen   
2011-01-04 11:56   
In version 1.9 @ revision 2832