Skip to content
  • Peter Maydell's avatar
    18e8ba48
    hw/arm/vexpress: Avoid trivial memory leak of 'flashalias' · 18e8ba48
    Peter Maydell authored
    
    
    In the vexpress board code, we allocate a new MemoryRegion at the top
    of vexpress_common_init() but only set it up and use it inside the
    "if (map[VE_NORFLASHALIAS] != -1)" conditional, so we leak it if not.
    This isn't a very interesting leak as it's a tiny amount of memory
    once at startup, but it's easy to fix.
    
    We could silence Coverity simply by moving the g_new() into the
    if() block, but this use of g_new(MemoryRegion, 1) is a legacy from
    when this board model was originally written; we wouldn't do that
    if we wrote it today. The MemoryRegions are conceptually a part of
    the board and must not go away until the whole board is done with
    (at the end of the simulation), so they belong in its state struct.
    
    This machine already has a VexpressMachineState struct that extends
    MachineState, so statically put the MemoryRegions in there instead of
    dynamically allocating them separately at runtime.
    
    Spotted by Coverity (CID 1509083).
    
    Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
    Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
    Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
    Message-id: 20230512170223.3801643-3-peter.maydell@linaro.org
    18e8ba48
    hw/arm/vexpress: Avoid trivial memory leak of 'flashalias'
    Peter Maydell authored
    
    
    In the vexpress board code, we allocate a new MemoryRegion at the top
    of vexpress_common_init() but only set it up and use it inside the
    "if (map[VE_NORFLASHALIAS] != -1)" conditional, so we leak it if not.
    This isn't a very interesting leak as it's a tiny amount of memory
    once at startup, but it's easy to fix.
    
    We could silence Coverity simply by moving the g_new() into the
    if() block, but this use of g_new(MemoryRegion, 1) is a legacy from
    when this board model was originally written; we wouldn't do that
    if we wrote it today. The MemoryRegions are conceptually a part of
    the board and must not go away until the whole board is done with
    (at the end of the simulation), so they belong in its state struct.
    
    This machine already has a VexpressMachineState struct that extends
    MachineState, so statically put the MemoryRegions in there instead of
    dynamically allocating them separately at runtime.
    
    Spotted by Coverity (CID 1509083).
    
    Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
    Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
    Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
    Message-id: 20230512170223.3801643-3-peter.maydell@linaro.org
Loading