• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-4070
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Normal Normal
Assignee: Soft Linden
Reporter: Carjay McGinnis
Votes: 1
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

OpenJPEG: LLImageJ2COJ::decodeImpl does not check if requested channel is higher than available

Created: 30/Dec/07 04:35 PM   Updated: 14/Mar/09 08:36 PM
Return to search
Component/s: Source Code
Affects Version/s: Source code
Fix Version/s: 1.22

File Attachments: 1. File openjpeg_check_number_of_components.diff (0.7 kB)
2. File openjpeg_check_number_of_components_1.20.diff (0.7 kB)

Environment: Linux Kubuntu Feisty x86_64
Issue Links:
Relates
 

Last Triaged: 19/Jun/08 04:30 PM
Linden Lab Issue ID: DEV-10215
Patch attached: Patch attached
Linden Lab Internal Branch: maint-viewer-9


 Description  « Hide
I have encountered a rare error condition (seems not to happen on all sims) where the OPENJPEG LLImageJ2COJ::decodeImpl method is called with the first_channel being higher than the number of channels (image->numcomps) in the J2K image (parsed from the header).

I have not verified what textures produce this but as far as I see from the sources this has something to do with masks for baked textures.

With the current viewer this leads to a crash because the number of components for the image size is calculated as 0 in this case so the size will become 0,
too. The error message will look like this: "LLImageBase::allocateData called with bad dimentions: 16x16x0"

I have attached a patch which catches this and simply flags the decoding as having failed.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Carjay McGinnis added a comment - 24/Apr/08 03:07 PM
added a patch against the current 1.20 code base since the original patch is applied to the wrong place now

Soft Linden added a comment - 07/Aug/08 12:24 PM
Thank you. The fix is visibly correct, so we'll take it in. If you're able to point to a specific sim where you've seen this happen, it would help with QA however.

Ramzi Linden added a comment - 21/Nov/08 10:44 AM
This should be fixed in version 1.22, which is currently in its Release Candidate phase.