Closed Bug 53494 Opened 24 years ago Closed 23 years ago

UMR in StretchDIBits

Categories

(Core :: Graphics: ImageLib, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED INVALID
mozilla0.9.3

People

(Reporter: jband_mozilla, Assigned: dcone)

Details

Attachments

(1 file)

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.
> rendering
Assignee: pnunn → kmcclusk
Don, here's one for you.
Assignee: kmcclusk → dcone
Status: NEW → ASSIGNED
Updating QA Contact
QA Contact: paw → tpreston
Target Milestone: --- → Future
I dont think this is happening anymore.. that line has been fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I'm sure don is good with his word, therefore I am verifying ;-)
Status: RESOLVED → VERIFIED
reopening bug; I"m seeing this again (perhaps due to new imglib?)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Target Milestone: Future → ---
Target Milestone: --- → mozilla0.9.3
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 ago23 years ago
Resolution: --- → INVALID
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.

Attachment

General

Creator:
Created:
Updated:
Size: