openexr weirdness on tobio (Re: [Bf-committers] sequencer crash)
Toni Alatalo
antont at kyperjokki.fi
Sun Mar 12 14:33:10 CET 2006
On Sunday 12 March 2006 00:06, Ton Roosendaal wrote:
> Thanks for the lecture. :)
indeed :)
> at his box. Seems like something else is wrong... not the code.
\o/
> BTW; it happens for him on any exr file Blender writes, used in
> sequencer. Quite simple to test. But I bet it will work fine on your
actually on reads,
if i e.g. open a .blend that has exr image sequencer strips
it crashes always immediately, in that thing i posted.
also with a clean cvs checkout,
and a clean build with normal versions of libraries.
> system too, sofar nobody was able to reproduce.
not even me :/
but antont at tobio:~ $ /mnt/orange/software/bassender -w
does the job :)
> -Ton-
~Toni
>
> On 10 Mar, 2006, at 20:20, Peter Schlaile wrote:
> > Hi,
> >
> > since I'm the only C++-coder around, I dived into the code:
> >
> > The interesting part of openexr_api.cpp is starting at line 625:
> > I commented the code a little bit, to explain the crash:
> >
> > if (!(flags & IB_test))
> > {
> > FrameBuffer frameBuffer; // here we construct a temporary
> > // FrameBuffer object on the stack
> > // there is a stl::map in it, that uses the
> > // heap, which is later globbered...
> >
> > // ... here we add Slices to the frameBuffer, that tell
> > readPixels
> > // where to write the data...
> >
> > // (*)
> > // Somewhere in here, most probably we added pointers / sizes
> > that
> > // point outside the limits.
> >
> > file->setFrameBuffer (frameBuffer);
> > // tell the input-object, where
> > // we want to write the data
> >
> > file->readPixels (dw.min.y, dw.max.y);
> > // read the data, probably thereby globbering the malloc-heap
> >
> > IMB_rect_from_float(ibuf);
> >
> > } // here frameBuffer loses scope and is destructed automatically
> > // triggering the segmentation fault
> >
> > To investigate this further:
> > - First try: please remove file->readPixels and see if it doesn't crash
> > anymore. Yes -> then I'm right, we made something wrong with the
> > slices.
> > Add it again and ...
> > - then: There are several frameBuffer.insert - method calls located
> > here
> > (*).
> > It is probably the best to remove these calls one by one and look,
> > when the segfault goes away.
> >
> > The bug is most probably triggered by a specific openexr-file. It is
> > most
> > likely a good idea to add some "fprintf-debug"-Statements, that show
> > xstride, ystride, width, height, dw.min.x, dw.min.y etc.
> >
> > If that doesn't help, send me an email (or give me an account on the
> > machine affected / send the openexr-file to me).
> >
> > Greetings,
> > Peter
> >
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at projects.blender.org
> > http://projects.blender.org/mailman/listinfo/bf-committers
>
> ------------------------------------------------------------------------
> --
> Ton Roosendaal Blender Foundation ton at blender.org
> http://www.blender.org
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
More information about the Bf-committers
mailing list