Closed
Bug 53494
Opened 24 years ago
Closed 23 years ago
UMR in StretchDIBits
Categories
(Core :: Graphics: ImageLib, defect, P3)
Tracking
()
VERIFIED
INVALID
mozilla0.9.3
People
(Reporter: jband_mozilla, Assigned: dcone)
Details
Attachments
(1 file)
2.99 KB,
text/plain
|
Details |
Purify shows a UMR (uninitialied memory read) in a call to StretchDIBits. It shows the alloc'd block to be the mImageBits. So, I assume, there are cases where not all bytes in the pixel data buffer get written. This may be harmless. I don't know - But StretchDIBits is actually trying to read the byte, so this is suspect. Sorry I don't have a URL - I was running under the browser buster. I'll attach the purify trace.
Reporter | ||
Comment 1•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → Future
Assignee | ||
Comment 5•23 years ago
|
||
I dont think this is happening anymore.. that line has been fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 6•23 years ago
|
||
I'm sure don is good with his word, therefore I am verifying ;-)
Status: RESOLVED → VERIFIED
Comment 7•23 years ago
|
||
reopening bug; I"m seeing this again (perhaps due to new imglib?)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Target Milestone: Future → ---
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.3
Assignee | ||
Comment 8•23 years ago
|
||
This is true, there can be uninitialized bits on an incremental load but we do limit this drawn area so the garbabe is not drawn. This UMR in StretchDIBits is happening.. but is not really a bug because we do this by design.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
Comment 9•23 years ago
|
||
Since this is done by design, I am marking verified
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•