MantisBT - CMake
View Issue Details
0013124CMakeCTestpublic2012-04-12 08:142013-01-09 10:55
Zog Zog 
Brad King 
normalmajoralways
closedfixed 
PCLinux
CMake 2.8.7 
CMake 2.8.9CMake 2.8.9 
0013124: UTF-8 characters disappear in valgrind output when launched via CTest
Got a C++ program which outputs in UTF-8.
When launched from command line, everything is OK.
When launched from valgrind from command line, it's OK.
When launched from CTest script ("ctest_test"), OK.
When launched from Valgrind from CTest script ("ctest_memcheck"), all utf-8 characters disappear from the output.

PS : please forgive my english.
No tags attached.
related to 0013136closed Brad King ctest_coverage() sets LC_ALL=POSIX but does not restore default 
Issue History
2012-04-12 08:14Zog ZogNew Issue
2012-04-12 11:51Brad KingNote Added: 0029139
2012-04-13 05:17Zog ZogNote Added: 0029147
2012-04-13 05:17Zog ZogNote Edited: 0029147bug_revision_view_page.php?bugnote_id=29147#r608
2012-04-13 05:17Zog ZogNote Edited: 0029147bug_revision_view_page.php?bugnote_id=29147#r609
2012-04-16 03:18Nils GladitzNote Added: 0029162
2012-04-16 04:10Nils GladitzNote Added: 0029165
2012-04-16 08:32Brad KingRelationship addedrelated to 0013136
2012-04-16 08:51Brad KingNote Added: 0029170
2012-04-23 05:28Zog ZogNote Added: 0029302
2012-04-23 05:28Zog ZogNote Edited: 0029302bug_revision_view_page.php?bugnote_id=29302#r623
2012-04-23 08:50Brad KingNote Added: 0029307
2012-04-23 08:50Brad KingStatusnew => resolved
2012-04-23 08:50Brad KingResolutionopen => fixed
2012-04-23 08:50Brad KingAssigned To => Brad King
2012-08-09 16:57David ColeFixed in Version => CMake 2.8.9
2012-08-09 16:57David ColeTarget Version => CMake 2.8.9
2013-01-09 10:55Robert MaynardNote Added: 0032019
2013-01-09 10:55Robert MaynardStatusresolved => closed

Notes
(0029139)
Brad King   
2012-04-12 11:51   
Does this patch solve the problem?

diff --git a/Source/CTest/cmCTestMemCheckHandler.cxx b/Source/CTest/cmCTestMemCheckHandler.cxx
index 035aaa9..3e4ecdd 100644                                                            
--- a/Source/CTest/cmCTestMemCheckHandler.cxx
+++ b/Source/CTest/cmCTestMemCheckHandler.cxx
@@ -358,7 +358,7 @@ void cmCTestMemCheckHandler::GenerateDartOutput(std::ostream& os)                  
 
     
os
       << "\t\t</Results>\n"
-      << logTag << memcheckstr << std::endl
+      << logTag << cmXMLSafe(memcheckstr) << std::endl
       << "\t</Log>\n";
     this->WriteTestResultFooter(os, result);
     if ( current < cc )
(0029147)
Zog Zog   
2012-04-13 05:17   
First, thank you for your quick reply !

Sadly, the patch doesn't solve the problem, accented characters are still missing and now, my ' turned into & apos;

(0029162)
Nils Gladitz   
2012-04-16 03:18   
Could this be locale related?

I've got a test which runs fine during a regular test run but fails when run through ctest_memcheck().

The error comes from a 3rd party library codecvt conversion.

Apparently for the valgrind run the environment variable LC_ALL is set to POSIX which when manually set makes the test fail in the same way.
(0029165)
Nils Gladitz   
2012-04-16 04:10   
I browsed through the sources and found ctest_coverage to be the only place where LC_ALL is set.

Without ctest_coverage() I can see that when running ctest_memcheck() LC_ALL is no longer set to POSIX.

I opened a new issue 0013136.

The UTF-8 encoding issue remains irregardless of LC_ALL.

I've got a test that outputs raw UTF-8 for a german umlaut and a chinese character both of which show up on CDash properly in a regular test run.

When run through ctest_memcheck() the umlaut shows up properly but the chinese character is replaced by a question mark.
(0029170)
Brad King   
2012-04-16 08:51   
Re 0013124:0029147: Please attach the .xml file generated by ctest_test for the test in question, and also that generated by ctest_memcheck with and without the patch.
(0029302)
Zog Zog   
2012-04-23 05:28   
The patch http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3247d63a [^] from issue http://public.kitware.com/Bug/view.php?id=13136 [^] resolved my problem ! Yay !

Thank you very much for the quick replies.

(0029307)
Brad King   
2012-04-23 08:50   
Addressed by fix to 0013136.
(0032019)
Robert Maynard   
2013-01-09 10:55   
Closing resolved issues that have not been updated in more than 4 months.