David Kastrup <d...@gnu.org> writes: > Neil Puttock <n.putt...@gmail.com> writes: > >> 2009/11/24 David Kastrup <d...@gnu.org>: >> >>> After applying <URL:http://codereview.appspot.com/160048> first, >>> indeed the following diff that throws out all the toplevel scoping >>> constructs and separate definitions of define-markup-command and >>> define-markup-list-command passes the regressions tests. Furthermore, >>> tests show that the namespace of markups defined in one input file does >>> not extend into the next input file. >> >> As far as I can see, all you've done is effectively revert Nicolas's >> code which fixed the memory leaks, so I can't see why it would work. >> >> I've just applied your patch, and as expected, I get the following >> errors with nearly every file (using a binary compiled with >> --disable-optimising): >> >> programming error: Parsed object should be dead: static >> scm_unused_struct* Prob::mark_smob(scm_unused_struct*) >> continuing, cross fingers >> programming error: Parsed object should be dead: static >> scm_unused_struct* Context_def::mark_smob(scm_unused_struct*) >> continuing, cross fingers > > I can't reproduce this with guile-1.8.7 and g++-4.4.1 from Ubuntu 9.10. > > The memory leak might possible be dealt with by putting the following > code into markup-init.ly:
I have uploaded a patch of that kind to Rietveld at <URL:http://codereview.appspot.com/160048>. Since our software versions appear to be the same and I fail to reproduce the error messages you get in spite of recompiling with ./configure --disable-optimising, it would also be helpful if you gave me a recipe on just what I should call from the command line in order to arrive at similar results. For the record: I get pretty much the same run time and memory usage on "make test" with none of my patch set applied, and with the latest version. The memory usage in either case grows larger than I think appropriate (slow start, but goes up to 400MB at the end), so quite apart from this particular patch set, I consider it likely that there is some memory leak that keeps information across the various tests of "make test". Thanks -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
