UMR of mModCount in nsEditor::IncrementModificationCount

VERIFIED FIXED in mozilla0.9.8

Status

SeaMonkey
Composer
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: John Morrison, Assigned: Brade)

Tracking

Trunk
mozilla0.9.8

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Purify reports a UMR here, in nsEditor.cpp:

    NS_IMETHODIMP nsEditor::IncrementModificationCount(PRInt32 inNumMods)
    {
      PRUint32 oldModCount = mModCount;

      mModCount += inNumMods;

      if ((oldModCount == 0 && mModCount != 0)
       || (oldModCount != 0 && mModCount == 0))
        NotifyDocumentListeners(eDocumentStateChanged);
      return NS_OK;
    }

inNumMods is 1, but mModCount is 0xdeadbeef. Just need to initialize in 
the constructor, I suppose. (Note: it doesn't report the UMR for every 
call to IncrementModificationCount, only for (I guess) the initial call).
(Assignee)

Comment 1

17 years ago
strange... I must have lost the initialization when preparing my patch.
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: --- → mozilla0.9.8
(Assignee)

Comment 2

17 years ago
*** Bug 114578 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 3

17 years ago
Created attachment 63815 [details] [diff] [review]
initialization in constructor
Comment on attachment 63815 [details] [diff] [review]
initialization in constructor

r=glazman
Attachment #63815 - Flags: review+
(Assignee)

Comment 5

17 years ago
fix checked in (sr=kin after changing order to not cause warning on Linux)
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
I can verify that this is fixed, at least from my testcast in bug 114578, on 
Windows 2000 under Purify.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.