On 2013/08/11 20:41:48, Keith wrote:
On Sun, 11 Aug 2013 12:46:04 -0700, <mailto:[email protected]> wrote:
>
https://codereview.appspot.com/12708048/diff/1/lily/side-position-interface.cc
> File lily/side-position-interface.cc (left): > >
https://codereview.appspot.com/12708048/diff/1/lily/side-position-interface.cc#oldcode216
> lily/side-position-interface.cc:216: Skyline my_dim; > > On 2013/08/11 19:30:46, Keith wrote: >> I am merely curious whether get_*_property() creates a temporary
copy
>> of the Scheme object.
> However, get_property can call callbacks, and then > the returned value is up for collection as soon as no SCM remains > referring to the returned value. >
That's it. The property in question is 'vertical-skylines' and it is
generated
by a callback. From the stacktrace we can determine that
get_*_property() was
called with pure==true to generate the object that is pointed to by
the copy of
'skyp' that is associated with the crash.
So get_*_property() used internal_get_pure_property() which returns
the computed
skylines as a SCM object /without/ storing it in the
'vertical-skylines'
property (because it wants to leave a pointer to callback there for
when we need
the real, unpure, skylines).
Well, I wanted to point out that the continuing presence of the problem when compiling without optimization makes this problem scenario unlikely since the SCM variable containing the returned value can't possibly be optimized out of existence. But it turns out that the original code never put the returned SCM value into a variable in the first place but rather unsmobbed it immediately. So yes, I'd definitely like to hear back whether current master still exhibits the problem. It's conceivable that this change helped, though there don't seem to be a lot of opportunities for garbage collection between return of the SCM value and use of the Skyline_pair. https://codereview.appspot.com/12708048/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
