[Cdash] loadXML problem revisited

[Sergio Vera]

Hi Zach,

I've just download the last version from svn, reinstalled and tested it,
adding the regexp that you've suggested. It works properly and handles the
badly encoded characters perfectly.

many thanks!



On Mon, Aug 29, 2011 at 4:36 PM, Zach Mullen <zach.mullen at kitware.com>wrote:

> On that note CDash devs, what should we do about this?  We could revert to
> the previous escaping regex, or devise a new one...  Thoughts?
>
> -Zach
>
>
> On Mon, Aug 29, 2011 at 10:34 AM, Zach Mullen <zach.mullen at kitware.com>wrote:
>
>> Hi Sergio,
>>
>> We fixed this bug before in revision 2832, but after some discussion
>> decided to limit the character replacement to only the case that was
>> currently breaking a user's dashboard, which was the escape character (see
>> revision 2833).  We said that we would expand the set of characters that we
>> escaped as needed, and now that appears to be the case.  As an immediate fix
>> for your issue, you can edit cdash/common.php line 161 and change it from:
>>
>>   $value = preg_replace_callback('/[\x1b]/',
>>
>> to:
>>
>>   $value = preg_replace_callback('/[^\x0A\x20-\x7E]/',
>>
>>
>> That should escape all non-ASCII characters and show them as "#dec" where
>> dec is their decimal value.
>>
>> Let me know if that doesn't work for you.
>>
>> Thanks,
>>
>>
>> On Mon, Aug 29, 2011 at 10:20 AM, Sergio Vera <sergio.vera at alma3d.com>wrote:
>>
>>> Hello all
>>> Our CDash Server (1.8.2)  still has problems with the some builds.
>>> The problem is that some test result pages don't render properly. The php
>>> responds with
>>> *
>>> *
>>> *Warning*: DOMDocument::loadXML() [domdocument.loadxml<http://frink/cdash/domdocument.loadxml>]:
>>> Input is not proper UTF-8, indicate encoding ! Bytes: 0xF3 0x6E 0x2F 0x44 in
>>> Entity, line: 69 in *C:\wamp\www\cdash\cdash\common.php* on line *42*
>>> *
>>> *
>>> then, the load of the page crashes, the css aren't read properly and a
>>> empty result page is shown.
>>>
>>> This problem is related with this bug
>>> http://public.kitware.com/Bug/view.php?id=10829
>>>
>>> We've traced the problem to a output of one of our tests that displays a
>>> path containing non ANSI characters (Z:/Investigación)  Visual Studio
>>> builds, seem to handle the encoding of such string withoud problems
>>> (displaying the messages and the test result page perfectly), while  MinGW /
>>> gcc tests that have that string on their output have the loadXML error. I
>>> suspect that either gcc/MinGW/msys or Cdash are doing something wrong with
>>> the encoding of the xml.
>>>
>>> At the moment we have solved the problem by removing the sentences that
>>> generate an output of the offending path but we wonder if there is a better
>>> method to resolve the encoding problem.
>>>
>>> Best regards.
>>>
>>> Sergio
>>>
>>> --
>>> Sergio Vera
>>>
>>>  Alma IT Systems
>>>  C/ Vilana, 4B, 4º 1ª
>>>  08022 Barcelona
>>>  T. (+34) 932 380 592
>>>  www.alma3d.com
>>>
>>> _______________________________________________
>>> Cdash mailing list
>>> Cdash at public.kitware.com
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/cdash
>>>
>>>
>>
>>
>> --
>> Zach Mullen
>> R & D Engineer
>> Kitware Inc.
>> (919) 969-6990 x314
>>
>>
>
>
> --
> Zach Mullen
> R & D Engineer
> Kitware Inc.
> (919) 969-6990 x314
>
>
> _______________________________________________
> Cdash mailing list
> Cdash at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/cdash
>
>


-- 
Sergio Vera

 Alma IT Systems
 C/ Vilana, 4B, 4º 1ª
 08022 Barcelona
 T. (+34) 932 380 592
 www.alma3d.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cdash/attachments/20110830/2be5ad49/attachment-0002.htm>