Closed
Bug 46525
Opened 25 years ago
Closed 25 years ago
UMR in OpenProcessToken called from PR_NT_InitSids [ntsec.c:80]
Categories
(NSPR :: NSPR, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
4.1
People
(Reporter: bratell, Assigned: wtc)
Details
Attachments
(1 file)
|
664 bytes,
patch
|
Details | Diff | Splinter Review |
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•25 years ago
|
||
|
|
Assignee | |
Updated•25 years ago
|
Target Milestone: --- → 4.1
|
|
Assignee | |
Comment 2•25 years ago
|
||
Does the proposed patch silence Purify?
|
Reporter | |
Comment 3•25 years ago
|
||
Yes it does.
|
|
Assignee | |
Comment 4•25 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
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 5•25 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•25 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.
Description
•