* [email protected] ([email protected]) wrote:
> Hi,
>
> Please find the latest report on new defect(s) introduced to LibreOffice
> found with Coverity Scan.
>
> 3 new defect(s) introduced to LibreOffice found with Coverity Scan.
> 571 defect(s), reported by Coverity Scan earlier, were marked fixed in the
> recent build analyzed by Coverity Scan.
>
> New defect(s) Reported-by: Coverity Scan
> Showing 3 of 3 defect(s)
(Reordering a bit)
> ** CID 1696359: Resource leaks (RESOURCE_LEAK)
> /sc/source/core/data/dptabres.cxx: 3841 in
> ScDPResultDimension::Promote(ScDPResultMemberSlim *, int)()
>
>
> _____________________________________________________________________________________________
> *** CID 1696359: Resource leaks (RESOURCE_LEAK)
> /sc/source/core/data/dptabres.cxx: 3841 in
> ScDPResultDimension::Promote(ScDPResultMemberSlim *, int)()
> 3835 if (pSlim->bmInitialized)
> 3836 pFull->SetInitialized();
> 3837
> 3838 // Remove the Slim from the memberarray but don't deallocate
> 3839 // We can't free it yet, because this Promote is called from
> Promote on
> 3840 // this Slim instance and it's caller may use the pointer again
> >>> CID 1696359: Resource leaks (RESOURCE_LEAK)
> >>> Ignoring storage allocated by
> >>> "this->maMemberArray[nIndex]->release()" leaks it.
> 3841 maMemberArray[nIndex].release();
> 3842
> 3843 maMemberArray[nIndex].reset(pFull);
> 3844
> 3845 // Stash the unpromoted member for later deletion - when this
> list is dropped
> 3846 maPromotedMembers.emplace_back(pSlim);
This is a recent change of mine, I believe this is a false positive, but I
understand why it's confused;
3819 ScDPResultMember* ScDPResultDimension::Promote(ScDPResultMemberSlim*
pSlim, SCROW nOrder)
...
3826 assert(pSlim == maMemberArray[nIndex].get());
...
3841 maMemberArray[nIndex].release();
...
3846 maPromotedMembers.emplace_back(pSlim);
It's complaining that I've leaked the data release()'d at nIndex; but the
assert at 3826 shows that this is the same as pSlim passed in, and
we actually stuff this onto the maPromotedMembers list
> ** CID 1696360: Null pointer dereferences (FORWARD_NULL)
>
>
> _____________________________________________________________________________________________
> *** CID 1696360: Null pointer dereferences (FORWARD_NULL)
> /sc/source/core/data/dptabres.cxx: 1600 in
> ScDPResultMember::FillMemberResults(com::sun::star::uno::Sequence<com::sun::star::sheet::MemberResult>
> *, long &, long, bool, const rtl::OUString *, const rtl::OUString *)()
> 1594 if (bTotalResult)
> 1595 {
> 1596 if (pMemberDesc)
> 1597 {
> 1598 // single data field layout.
> 1599 const std::optional<OUString> & pSubtotalName =
> pParentDim->GetSubtotalName();
> >>> CID 1696360: Null pointer dereferences (FORWARD_NULL)
> >>> Passing null pointer "pSubtotalName" to "operator bool", which
> >>> dereferences it.
> 1600 if (pSubtotalName)
> 1601 aSubStr =
> lcl_parseSubtotalName(*pSubtotalName, aCaption);
> 1602 pArray[rPos].Flags &=
> ~sheet::MemberResultFlags::GRANDTOTAL;
This block hasn't changed in ages (other code in the function has); last change
here was ~2020;
I think this code is assuming that if the std::optional has data that it's a
valid string pointer;
is that unreasonable?
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
