Re: [openvrml-develop] material-rendering bug

[Braden M. <br...@en...>]

On Mon, 2010-05-03 at 02:26 -0400, Braden McDaniel wrote: 
> On Thu, 2010-04-01 at 15:57 -0400, Braden McDaniel wrote: 
> > On 3/29/10 4:58 PM, Braden McDaniel wrote:
> > > I'm still trying to get a handle on exactly what's going on
> > > here.  I'm getting closer; I think I'm looking at a race between some
> > > stream handling threads.  But I haven't isolated it yet.
> > 
> > This may or may not be the case.  Regardless, there is definitely
> > something screwy going on in the PNG decoder.  I think what's happening
> > is that for some images, the decoder is not detecting the number of
> > pixel components correctly and consequently isn't giving libpng a big
> > enough buffer to work with.  libpng calls then proceed to stomp all over
> > memory (which on my machine appears consistently to be the browser's
> > node_metatype_registry); hilarity ensues.
> 
> This bug continues to elude me. :-(
> 
> I have discovered a few things...
> 
>       * Even if I comment out all of the texture URLs in pngboxes.wrl, I
>         get a segfault in sdl-viewer occasionally.  So there's
>         *something* screwy going on irrespective of the image loading
>         code.

I still need to investigate this further...

> * One somewhat ominous looking message I'm getting from valgrind
>         is pointing to my Spirit-based node metatype identifier parser
>         (which is just a minor augmentation of my URI parser).

I tried updating the URI parser to use Spirit2; and this did get rid of
the ominous valgrind message.  It did not, however, fix The Problem.

I did finally discover a problem in the PNG reader that was leading to
memory corruption.  I've committed a fix for this on the trunk and the
0.18 branch.  This has certainly addressed a significant problem with
pngboxes.wrl; though I'm not sure it was the only problem.

I'll be out of town this weekend; so it will probably be sometime next
week before I'm able to test things more thoroughly.  In the meantime,
the changes have been committed in case anyone else is interested in
taking them for a spin.

-- 
Braden McDaniel <br...@en...>