UMR in OpenProcessToken called from PR_NT_InitSids [ntsec.c:80]

RESOLVED FIXED in 4.1

Status

P3
trivial
RESOLVED FIXED
18 years ago
18 years ago

People

(Reporter: bratell, Assigned: wtc)

Tracking

other
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
When running Mozilla today on Windows 2000 I notice an Unintialized Memory Read 
in OpenProcessToken. It's the last parameter hToken that's not initialized. As 
far as I can see we shouldn't have to either but it's probably a bug in 
Windoes. Maybe we could null it or something just to silence Purify. For the 
moment, it's the only warning during startup in my local tree. (I have some code 
that's not checked in yet.)
(Assignee)

Comment 1

18 years ago
Created attachment 12110 [details] [diff] [review]
Proposed patch.
(Assignee)

Updated

18 years ago
Target Milestone: --- → 4.1
(Assignee)

Comment 2

18 years ago
Does the proposed patch silence Purify?
(Reporter)

Comment 3

18 years ago
Yes it does. 
(Assignee)

Comment 4

18 years ago
I checked in the patch on the main trunk.
/cvsroot/mozilla/nsprpub/pr/src/md/windows/ntsec.c, revision 3.5
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 5

18 years ago
I don't see this fixed in Mozilla (Seamonkey). Is this using another version of 
NSPR than the one you fixed it on?
(Assignee)

Comment 6

18 years ago
Yes, Mozilla (SeaMonkey) is using the NSPRPUB_CLIENT_BRANCH
of NSPR.  I checked in the fix on the main trunk of NSPR.

Only critical bug fixes can be checked in on the NSPRPUB_CLIENT_BRANCH.
You need to log in before you can comment on or make changes to this bug.