On Sun, Jun 16, 2019 at 1:15 AM Palmer Dabbelt wrote:
>
> On Fri, 14 Jun 2019 05:25:50 PDT (-0700), phi...@redhat.com wrote:
> > On 6/14/19 2:08 PM, Palmer Dabbelt wrote:
> >> Coverity pointed out a memory leak in riscv_sifive_e_soc_realize(),
> >> where a pair of recently added MemoryRegion insta
On Fri, 14 Jun 2019 05:25:50 PDT (-0700), phi...@redhat.com wrote:
On 6/14/19 2:08 PM, Palmer Dabbelt wrote:
Coverity pointed out a memory leak in riscv_sifive_e_soc_realize(),
where a pair of recently added MemoryRegion instances would not be freed
if there were errors elsewhere in the function
On 6/14/19 2:08 PM, Palmer Dabbelt wrote:
> Coverity pointed out a memory leak in riscv_sifive_e_soc_realize(),
> where a pair of recently added MemoryRegion instances would not be freed
> if there were errors elsewhere in the function. The fix here is to
> simply not use dynamic allocation for th
Coverity pointed out a memory leak in riscv_sifive_e_soc_realize(),
where a pair of recently added MemoryRegion instances would not be freed
if there were errors elsewhere in the function. The fix here is to
simply not use dynamic allocation for these instances: there's always
one of each in SiFiv
