Possible null pointer dereference in nsAFMObject.cpp

RESOLVED FIXED

Status

()

--
minor
RESOLVED FIXED
13 years ago
5 months ago

People

(Reporter: kherron+mozilla, Assigned: srini)

Tracking

(Blocks: 1 bug, {coverity})

Trunk
All
Linux
coverity
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [good first bug], URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
This was found through a coverity scan of the mozilla source. Please refer to the sample URL. The nsAFMObject dtor is as follows:

217 nsAFMObject :: ~nsAFMObject()
218 {
219 
220   if(mPSFontInfo->mAFMCharMetrics){
221     delete [] mPSFontInfo->mAFMCharMetrics;
222   }
223 
224   if(mPSFontInfo){
225     delete mPSFontInfo;
226   }
227 }

mPSFontInfo is set to null in the ctor so it could be null at line 220. In any event, it makes no sense to test mPSFontInfo for null at line 224 after dereferencing it at line 220.
(Reporter)

Updated

13 years ago
Whiteboard: [good first bug]
Keywords: coverity
(Assignee)

Comment 1

13 years ago
A safe fix would be to change this to:

nsAFMObject :: ~nsAFMObject()
{

  if (mPSFontInfo){
    if(mPSFontInfo->mAFMCharMetrics){
      delete [] mPSFontInfo->mAFMCharMetrics;
    }
    delete MPSFontInfo;
  }

}
(Assignee)

Comment 2

13 years ago
(In reply to comment #1)
> A safe fix would be to change this to:

Oops, not that safe...

>     delete MPSFontInfo;

... should be:

      delete mPSFontInfo;

Sorry for the case typo.
(Assignee)

Comment 3

13 years ago
Created attachment 221561 [details] [diff] [review]
Initial patch

First go at a patch.
Assignee: printing → srini
Checked in to trunk.  Thanks for the patch!
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.