[sldev] Crash reports analysis [http-texture builds]

Rob Lanphier robla at lindenlab.com
Thu May 14 09:39:47 PDT 2009


Reviving old discussion.....

On 04/30/2009 03:00 AM, Robin Cornelius wrote:
> On Thu, Apr 30, 2009 at 7:23 AM, Philippe Bossut (Merov Linden)
> <merov at lindenlab.com> wrote:
>   
>> The OpenJPEG crashers are concerning. There are unfortunately little
>> info in the stack trace and I haven't myself experienced that one.
>> What's strange is that I looked into the other viewers crash logs
>> (thousands of them) and it doesn't surface at all in their crashers.
>> May be of note: our 2 crashers happen on Vista. Does this ring a bell
>> to anyone?
>>     
> I surprised that that you have not had more reports on this. Certainly
> some of us have seen this fairly frequently who are building ourselves
> and it usually is triggers from the LLImageJ2COJ::getMetadata() during
> some where in opj_image_destroywhen a wild pointer is freed (possible
> also related to a bad image being fed to decode). This is fixed in
> openjpeg SVN and i think those of us on #opensl who are building
> http-texture already have this patched (or at least a good few do).
> Although its possible (I would need to confirm) that we see it because
> this was introduced in openjpeg 1.3 and LL are still on 1.2 internally
> and also this could explain why we don't see any other crashes here.
>
> Looking at http://www.openjpeg.org/websvn/filedetails.php?repname=OpenJpeg&path=%2Ftrunk%2Flibopenjpeg%2Fimage.c&rev=0&sc=0
>
> the opj_free(image->comps);
>
> is the offending line, note in the SVN web view the structures are
> allocated with opj_calloc() where as the older code uses opj_malloc()
> which does not null the pointers.
>
> There may also need to be some viewer sanity checking here as well as
> various image-> members are used in LLImageJ2COJ::getMetadata() and
> although i've not see a crash directly because of their use after
> patching openjpeg its probably worth investigating to ensure no edge
> case is creeping in here.
>   
Well....this seems like a concerning thing to let just lay around. I've
got a few questions about this:
1. The SLDev Viewer should be using KDU by default. Is there some
functionality (e.g. the new map) that uses OpenJPEG by default, even if
KDU is available?
2. Is there something in JIRA about this particular issue already?
3. Since this bug isn't fixed in OpenJPEG 1.3, but the release timeline
for OpenJPEG 2.0 doesn't look clear, what would be the odds of
convincing the OpenJPEG team to ship an OpenJPEG 1.3.1. We've got a
strong preference to stick with releases rather than svn snapshots.
4. If an OpenJPEG 1.3.1 isn't in the cards, it seems like we should suck
it up and patch our OpenJPEG. Right?
5. Is the currently shipping SLDev Viewer build still on 1.2?

Some of these I'll be able to research myself, but I also know there are
many of you who know this off the tops of your respective heads.

Rob



More information about the SLDev mailing list