[Bf-committers] Re: sequencer crash

Shaul Kedem shaul.kedem at gmail.com
Fri Mar 10 12:32:19 CET 2006


Just so everyone will be up to speed, a destructor is a function within a
class which gets called when the class reach a point where it is no longer
needed. This may happen explicitly (calling "delete" which is like "free" in
c) or implicitly; for example, when a scope is ended and there are automatic
variables defined (like in the example branan is giving).

C++ does not free memory whenever it wants to, it has a formal way of doing
it, the problem is when you don't know these activities are taking place in
the background.

see on destructors:
http://en.wikipedia.org/wiki/Destructor_%28computer_science%29

Shaul

On 3/10/06, Ton Roosendaal <ton at blender.org> wrote:
>
> Hi,
>
> >> source/blender/imbuf/intern/openexr/openexr_api.cpp
>
> or webcvs:
>
> http://projects.blender.org/viewcvs/viewcvs.cgi/blender/source/blender/
> imbuf/intern/openexr/openexr_api.cpp?rev=1.7&cvsroot=bf-
> blender&content-type=text/vnd.viewcvs-markup
>
> -Ton-
>
>
> On 10 Mar, 2006, at 0:10, Branan Riley wrote:
>
> > I'm new at the blender code, but I know c++. I can't find the file
> > that it's in for the life of me, so if someone could check if
> > InputFile::setFrameBuffer() has "FrameBuffer X" as it's argument, or
> > "FrameBuffer& X" If it's the first, it's a c-style pass-by-value, so
> > it's actually creating a new copy of the class/structure when it's
> > called, hence the destructor call. "FrameBuffer& X" is a
> > pass-by-reference, which is really like passing a pointer (that's what
> > it does internally), except it's accessed with the normal operators,
> > not the pointer operators.
> >
> > On 3/9/06, Ton Roosendaal <ton at blender.org> wrote: Hi,
> >>
> >> > Hi Toni,
> >> >
> >> >> with an exr sequence, i dont know what happens
> >> >
> >> > looks more like an openexr-crash than a sequencer-crash to me.
> >> >
> >> > Especially:
> >> >
> >> >> #15 0x084b7bf3 in ~FrameBuffer (this=0xbfccce20) at
> >> >> ImfFrameBuffer.h:120
> >> >> #16 0x084b6db1 in imb_load_openexr (mem=0xb49bc000 "v/1\001\002",
> >> >> size=1601687, flags=1)
> >> >> at source/blender/imbuf/intern/openexr/openexr_api.cpp:656
> >> >
> >> > These lines are suspicious. Why does the code call the
> >> > FrameBuffer-destructor on load (haven't dived into openexr-support,
> >> > maybe
> >> > it's ok).
> >>
> >> I have no idea either... not a c++ coder here. C++ seems to have a
> >> magical way of freeing memory.
> >> Could you check the imb_load_openexr() call please? Maybe something
> >> stupid happens there...
> >>
> >> -Ton-
> >>
> >> >
> >> > Greetings,
> >> > Peter
> >> >
> >> > _______________________________________________
> >> > Bf-committers mailing list
> >> > Bf-committers at projects.blender.org
> >> > http://projects.blender.org/mailman/listinfo/bf-committers
> >> >
> >> >
> >> ----------------------------------------------------------------------
> >> --
> >> --
> >> Ton RoosendaalBlender 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
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.blender.org/pipermail/bf-committers/attachments/20060310/f49b0c1b/attachment.html


More information about the Bf-committers mailing list