|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
On 16/04/2020 12:36, Wieczorkiewicz, Pawel wrote:
>> Unfortunately, this comes with collateral damage.
>>
>> # ./xtf-runner hvm64 example
>> Executing 'xl create -p tests/example/test-hvm64-example.cfg'
>> Executing 'xl console test-hvm64-example'
>> Executing 'xl unpause test-hvm64-example'
>> --- Xen Test Framework ---
>>
>> Found Xen: 4.14
>>
>> Environment: HVM 64bit (Long mode 4 levels)
>>
>> Hello World
>>
>> Test result: SUCCESS
>>
>>
>> Combined test results:
>> test-hvm64-example CRASH
>>
> I never use xtf-runner script to execute tests. I do it the old fashion way:
>
> # xl create -c test-hvm64-example.cfg
> Parsing config from test-hvm64-example.cfg
I presume you mean hvm64-cpuid here, but...
> Guest cpuid information
> Native cpuid:
> 00000000:ffffffff ->
> 0000000d:756e6547:6c65746e:49656e69
>
> 00000001:ffffffff -> 000306e4:00400800:f7ba2203:1fcbfbff
>
>
> 00000002:ffffffff -> 76036301:00f0b2ff:00000000:00ca0000
> 00000003:ffffffff -> 00000000:00000000:00000000:00000000
> 00000004:00000000
> -> 7c000121:01c0003f:0000003f:00000000
>
> 00000004:00000001 ->
> 7c000122:01c0003f:0000003f:00000000
>
>
> 00000004:00000002 -> 7c000143:01c0003f:000001ff:00000000
>
>
>
> 00000004:00000003 -> 7c000163:04c0003f:00004fff:00000006
> 00000004:00000004 -> 00000000:00000000:00000000:00000000
> 00000005:ffffffff
> -> 00000040:00000040:00000003:00001120
>
> 00000006:ffffffff ->
> 00000077:00000002:00000009:00000000
>
>
> 00000007:00000000 -> 00000000:00000281:00000000:9c000400
>
>
>
> 00000008:ffffffff -> 00000000:00000000:00000000:00000000
> 00000009:ffffffff -> 00000000:00000000:00000000:00000000
> 0000000a:ffffffff
> -> 07300403:00000000:00000000:00000603
>
> 0000000b:ffffffff ->
> 00000000:00000000:00000000:00000000
>
>
> 0000000c:ffffffff -> 00000000:00000000:00000000:00000000
>
>
>
> 0000000d:00000000 -> 00000007:00000240:00000340:00000000
> 0000000d:00000001 -> 00000001:00000000:00000000:00000000
>
> 0000000d:00000002 -> 00000100:00000240:00000000:00000000
>
> 40000000:ffffffff ->
> 40000005:566e6558:65584d4d:4d4d566e
>
>
> 40000001:ffffffff -> 0004000b:00000000:00000000:00000000
>
>
>
> 40000002:ffffffff -> 00000001:40000000:00000000:00000000
> 40000003:00000000 -> 00000006:00000000:002625a2:00000001
>
> 40000003:00000001 -> 57b3c4d2:00030755:ccccc210:ffffffff
>
> 40000003:00000002 ->
> 002625a2:00000000:00000000:00000000
>
>
> 40000004:00000000 -> 0000001c:00000000:00000ac9:00000000
>
>
>
> 40000005:ffffffff -> 00000000:00000000:00000000:00000000
> 40000100:ffffffff -> 00000000:00000000:00000000:00000000
>
> 80000000:ffffffff -> 80000008:00000000:00000000:00000000
>
> 80000001:ffffffff ->
> 00000000:00000000:00000001:2c100800
>
>
> 80000002:ffffffff ->
> 20202020:6e492020:286c6574:58202952
>
>
>
> 80000003:ffffffff -> 286e6f65:43202952:45205550:36322d35
> 80000004:ffffffff -> 76203037:20402032:30352e32:007a4847
>
> 80000005:ffffffff -> 00000000:00000000:00000000:00000000
>
> 80000006:ffffffff ->
> 00000000:00000000:01006040:00000000
>
>
> 80000007:ffffffff ->
> 00000000:00000000:00000000:00000000
>
>
>
> 80000008:ffffffff -> 0000302e:00001000:00000000:00000000
> Test result: SUCCESS
... I have reproduced this locally.
However, I'd argue that this it is a bug in xenconsoled rather than
XTF. In particular, modifying XTF would result in xenconsoled writing
out the logfile with windows line endings, which surely isn't intended.
>>> ---
>>> common/libc/vsnprintf.c | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
>>> index a49fd30..3202137 100644
>>> --- a/common/libc/vsnprintf.c
>>> +++ b/common/libc/vsnprintf.c
>>> @@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
>>> va_list args)
>>> if ( *fmt != '%' )
>>> {
>>> PUT(*fmt);
>>> +
>>> + /*
>>> + * The '\n' character alone on some terminals is not
>>> automatically
>>> + * converted to LFCR.
>>> + * The explicit LFCR sequence guarantees proper line by line
>>> + * formatting in the output.
>>> + */
>>> + if ( *fmt == '\n' && str < end )
>>> + PUT('\r');
>> ... doesn't this end up putting out \n\r ?
> yes, it does
So the one type of line ending which isn't in common use?
~Andrew
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |