[Xen-devel] [ovmf baseline-only test] 75546: regressions - FAIL

[Platform Team regression test user <citrix-osstest@xxxxxxxxxxxxxx>]

This run is configured for baseline tests only.

flight 75546 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75546/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 75543
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 75543

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt           6 libvirt-build                fail   like 75543
 build-i386-libvirt            6 libvirt-build                fail   like 75543

version targeted for testing:
 ovmf                 4222e8e7e421e9c8d2c2f319a3860dd3332d6255
baseline version:
 ovmf                 c87ac38cf280fa969f1033de3c5b7a157aac8cbc

Last test of basis    75543  2018-10-30 05:31:10 Z    0 days
Testing same since    75546  2018-10-30 09:21:34 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jian J Wang <jian.j.wang@xxxxxxxxx>
  Marvin H?user <Marvin.Haeuser@xxxxxxxxxxx>
  Marvin Haeuser <Marvin.Haeuser@xxxxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    


------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
    http://osstest.xensource.com/osstest/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.

------------------------------------------------------------
commit 4222e8e7e421e9c8d2c2f319a3860dd3332d6255
Author: Marvin H?user <Marvin.Haeuser@xxxxxxxxxxx>
Date:   Sun Oct 28 16:51:23 2018 +0800

    UefiCpuPkg/PiSmmCpuDxeSmm: Fix ASSERT for success.
    
    Index is initialized to MAX_UINT16 as default failure value, which
    is what the ASSERT is supposed to test for.  The ASSERT condition
    however can never return FALSE for INT16 != int, as due to
    Integer Promotion[1], Index is converted to int, which can never
    result in -1.
    
    Furthermore, Index is used as a for loop index variable inbetween its
    initialization and the ASSERT, so the value is unconditionally
    overwritten too.
    
    Fix the ASSERT check to compare Index to its upper boundary, which it
    will be equal to if the loop was not broken out of on success.
    
    [1] ISO/IEC 9899:2011, 6.5.9.4
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Marvin Haeuser <Marvin.Haeuser@xxxxxxxxxxx>
    Reviewed-by: Eric Dong <eric.dong@xxxxxxxxx>

commit 37fba7c2762e114a280e3b361b53ded034aac7e3
Author: Marvin H?user <Marvin.Haeuser@xxxxxxxxxxx>
Date:   Sun Oct 28 16:51:22 2018 +0800

    UefiCpuPkg/MpInitLib: Fix ASSERT for success.
    
    Index is initialized to MAX_UINT16 as default failure value, which
    is what the ASSERT is supposed to test for.  The ASSERT condition
    however can never return FALSE for INT16 != int, as due to
    Integer Promotion[1], Index is converted to int, which can never
    result in -1.
    
    Furthermore, Index is used as a for loop index variable inbetween its
    initialization and the ASSERT, so the value is unconditionally
    overwritten too.
    
    Fix the ASSERT check to compare Index to its upper boundary, which it
    will be equal to if the loop was not broken out of on success.
    
    [1] ISO/IEC 9899:2011, 6.5.9.4
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Marvin Haeuser <Marvin.Haeuser@xxxxxxxxxxx>
    Reviewed-by: Eric Dong <eric.dong@xxxxxxxxx>

commit 61a62fc2587ae4d01718124f28e1ea0e60375902
Author: Jian J Wang <jian.j.wang@xxxxxxxxx>
Date:   Mon Oct 29 16:20:44 2018 +0800

    MdeModulePkg/Core: fix an issue of potential NULL pointer access
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1286
    
    This issue is introduced by bb685071c2602cf786ea84c69bbebf2158194a38.
    
    The *MemorySpaceMap assigned with NULL (line 1710) value might be
    accessed (line 1726/1730) without any sanity check. Although it won't
    happen in practice because of line 1722, we still need to add check
    against NULL to make static code analyzer happy.
    
    1710  *MemorySpaceMap       = NULL;
    ....  ...
    1722  if (DescriptorCount == *NumberOfDescriptors) {
    ....  ...
    1726    Descriptor = *MemorySpaceMap;
    ....  ...
    1730        BuildMemoryDescriptor (Descriptor, Entry);
    
    Tests:
      Pass build and boot to shell.
    
    Cc: Hao Wu <hao.a.wu@xxxxxxxxx>
    Cc: Star Zeng <star.zeng@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Jian J Wang <jian.j.wang@xxxxxxxxx>
    Reviewed-by: Hao Wu <hao.a.wu@xxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel