Open Bug 1231132 Opened 4 years ago Updated 4 years ago

[Static Analysis][Uninitialized scalar field] SheetLoadData::SheetLoadData from Loader.cpp


(Core :: CSS Parsing and Computation, defect)

Not set



Tracking Status
firefox45 --- affected


(Reporter: andi, Assigned: andi)


(Blocks 1 open bug)


(Keywords: coverity, Whiteboard: CID 1327955 )


(2 files)

The Static Analysis tool Coverity added that member variable mStatus is not initialized in constructors.
Attached patch Bug 1231132.diffSplinter Review
Hello David,

Can you please take a look other this patch. it's not big deal, just added a member variable to the constructors.
Attachment #8696691 - Flags: review?(dbaron)
Comment on attachment 8696691 [details] [diff] [review]
Bug 1231132.diff

This is probably ok, but you should update the comment which explains when this is initialized/used to talk about setting, not initializing, right?
Flags: needinfo?(bogdan.postelnicu)
Hello Boris,

Thank you for letting me know. The variable - mStatus should be set in the 3 constructors that have parameters. 
Other place where mStatus is set is in function SheetLoadData::ScheduleLoadEventIfNeeded:

>>  if (!mOwningElement) {
>>    return;
>>  }

>>  mStatus = aStatus;

ScheduleLoadEventIfNeeded gets called from Loader::DoSheetComplete:

>>    if (!data->mSheetAlreadyComplete) {
>>      // If mSheetAlreadyComplete, then the sheet could well be modified between
>>      // when we posted the async call to SheetComplete and now, since the sheet
>>      // was page-accessible during that whole time.
>>      MOZ_ASSERT(!data->mSheet->IsModified(),
>>                 "should not get marked modified during parsing");
>>      data->mSheet->SetComplete();
>>      data->ScheduleLoadEventIfNeeded(aStatus);
>>    }

On the other hand Loader::DoSheetComplete gets called on 2 routes:

1. from itself recursively:
>>    if (data->mParentData &&
>>        --(data->mParentData->mPendingChildren) == 0 &&
>>        !mParsingDatas.Contains(data->mParentData)) {
>>      DoSheetComplete(data->mParentData, aStatus, aDatasToNotify);
>>    }

2. from path: SheetLoadData::Run(..)->Loader::HandleLoadEvent(..)->Loader::SheetComplete(..)->Loader::DoSheetComplete(..)

I cannot tell you for sure that having mStatus not set in those constructors can cause a bug, the fix is more to silence Coverity. If you need more info please let me know and i'll do my best to privide it.

Flags: needinfo?(bogdan.postelnicu)
There is no actual bug here: the only code that _reads_ mStatus runs only if ScheduleLoadEventIfNeeded has been called.  So the patch is not really needed, but doesn't hurt anything either.

My point was that the patch should update the comment that explains all this and describes the current setup (which you're changing).  That comment is right above the declaration of mStatus.
Thx, now i understand, i didn't got that you were referring to the actual comment from the cpp.
Comment on attachment 8696691 [details] [diff] [review]
Bug 1231132.diff

Could you update the patch as requested?
Attachment #8696691 - Flags: review?(dbaron)
That said, I also have mixed feelings about taking patches of this sort, since it means we lose the potential to learn about problems from valgrind warnings.  I guess I'm ok with them, though.
David if toy want there is always the possibility to wave it from Coverity and mark it as ignore.
Comment on attachment 8717824 [details]
MozReview Request: Bug 1231132 - setting mStatus in constructors to NS_OK in order to silence a Coverity checker. It's not a bug since this gets set by ScheduleLoadEventIfNeeded, and is only used after that has been called. r?dbaron

Could you add a call to MOZ_MAKE_MEM_UNDEFINED() in all 3 constructors to declare that the memory occupied by mStatus is still considered undefined?  That would address the valgrind issue and also avoid the need to update the comment as Boris requested in comment 2 and comment 4 (and which I'm a little surprised that this patch hasn't updated, given those comments
Attachment #8717824 - Flags: review?(dbaron)
You need to log in before you can comment on or make changes to this bug.