Re: Parsed object should be dead
Am Sonntag, dem 07.02.2021 um 23:16 +0100 schrieb Han-Wen Nienhuys: > On Sat, Feb 6, 2021 at 7:33 PM Dan Eble wrote: > > > Did something change in the past couple of weeks to make "Parsed object > > should be dead" messages more likely? Now that I've turned from > > documentation back to development, they seem to be getting in my way much > > more than they used to. > > > > This stands out: > > > > commit d1be5ec60a058e363835bee60ece6fc61a67c5a9 > > Author: Han-Wen Nienhuys > > Date: Sun Jan 24 16:50:19 2021 +0100 > > > > Introduce 'debug-gc-lifetimes option > > > > The debug-gc-assert-parsed-dead feature has been documented, but it is > > really an internal mechanism (it only has effect during garbage > > collection, and has to be coupled with calls to ly:parsed-undead-list! > > in order to do something useful. > > > > Instead, introduce the debug-gc-object-lifetimes option, which > > controls the entire check (ie. the extra GC call, and the printing of > > objects afterwards). For backward compatibility, this feature defaults > > to #t. > > > > I wonder if we could disable this by default. As a user, I don't like > > getting 672 lines of console output when I would have gotten 31 with this > > option disabled. > > > > I think we should default debug-gc-object-lifetimes to #f, and set it to #t > for the regression test suite. Note that --enable-checking is off by default already, so the check actually doesn't do anything. Also, as far as I understand, once we disable 'debug-gc-object-lifetimes there will be no (gc) between the files and the GC bug in the released versions of Guile 1.8 will trigger, leading to excessive memory usage. signature.asc Description: This is a digitally signed message part
Re: Parsed object should be dead
On Sat, Feb 6, 2021 at 7:33 PM Dan Eble wrote: > Did something change in the past couple of weeks to make "Parsed object > should be dead" messages more likely? Now that I've turned from > documentation back to development, they seem to be getting in my way much > more than they used to. > > This stands out: > > commit d1be5ec60a058e363835bee60ece6fc61a67c5a9 > Author: Han-Wen Nienhuys > Date: Sun Jan 24 16:50:19 2021 +0100 > > Introduce 'debug-gc-lifetimes option > > The debug-gc-assert-parsed-dead feature has been documented, but it is > really an internal mechanism (it only has effect during garbage > collection, and has to be coupled with calls to ly:parsed-undead-list! > in order to do something useful. > > Instead, introduce the debug-gc-object-lifetimes option, which > controls the entire check (ie. the extra GC call, and the printing of > objects afterwards). For backward compatibility, this feature defaults > to #t. > > I wonder if we could disable this by default. As a user, I don't like > getting 672 lines of console output when I would have gotten 31 with this > option disabled. > I think we should default debug-gc-object-lifetimes to #f, and set it to #t for the regression test suite. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Parsed object should be dead
Am Samstag, dem 06.02.2021 um 13:33 -0500 schrieb Dan Eble: > Did something change in the past couple of weeks to make "Parsed > object should be dead" messages more likely? Now that I've turned > from documentation back to development, they seem to be getting in my > way much more than they used to. The warning got more "correct" with: commit e73cf1a7b2ce72d488afef8083b933c9fb6ebc36 Author: Han-Wen Nienhuys Date: Sat Jan 30 10:34:22 2021 +0100 Make -ddebug-gc-object-lifetimes more robust and now warns if any object is leaked. Before only one object was reported per smob type and it was basically luck if that was ignored because of the session or reported as "should be dead". The problem is tracked at https://gitlab.com/lilypond/lilypond/-/issues/6079 and there Han-Wen found that objects are reported this way if the first file of a forked process contains variables. My understanding is that this issue exists since the introduction of sessions, the only thing that changed is that it now gets properly reported. Jonas signature.asc Description: This is a digitally signed message part
Parsed object should be dead
Did something change in the past couple of weeks to make "Parsed object should be dead" messages more likely? Now that I've turned from documentation back to development, they seem to be getting in my way much more than they used to. This stands out: commit d1be5ec60a058e363835bee60ece6fc61a67c5a9 Author: Han-Wen Nienhuys Date: Sun Jan 24 16:50:19 2021 +0100 Introduce 'debug-gc-lifetimes option The debug-gc-assert-parsed-dead feature has been documented, but it is really an internal mechanism (it only has effect during garbage collection, and has to be coupled with calls to ly:parsed-undead-list! in order to do something useful. Instead, introduce the debug-gc-object-lifetimes option, which controls the entire check (ie. the extra GC call, and the printing of objects afterwards). For backward compatibility, this feature defaults to #t. I wonder if we could disable this by default. As a user, I don't like getting 672 lines of console output when I would have gotten 31 with this option disabled. — Dan
Avoid Parsed object should be dead message from issue 4505 (issue 258030043 by d...@gnu.org)
LGTM https://codereview.appspot.com/258030043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead with LilyDev 3
On 26/10/14 02:49, Dan Eble wrote: Does anyone else see a lot of “Parsed object should be dead” programming errors in the regression test logs? — Dan As another example: https://code.google.com/p/lilypond/issues/detail?id=4156 See comment #5 onwards. I think you're hitting the kind of thing I do occasionally when I test patches. It's probably benign. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead with LilyDev 3
Dan Eble d...@faithful.be writes: Does anyone else see a lot of “Parsed object should be dead” programming errors in the regression test logs? They occur sometimes. If they are a regular, they might point to a problem. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead with LilyDev 3
On Oct 26, 2014, at 08:35 , David Kastrup d...@gnu.org wrote: Dan Eble d...@faithful.be writes: Does anyone else see a lot of “Parsed object should be dead” programming errors in the regression test logs? They occur sometimes. If they are a regular, they might point to a problem. OK, thanks. The reason I noticed them is that they were not regular. For the record, I never saw them before upgrading to LilyDev 3. Although I didn’t scrutinize the test logs every time I ran the tests, I never noticed these messages on the occasions that I did read closely. — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead with LilyDev 3
Does anyone else see a lot of “Parsed object should be dead” programming errors in the regression test logs? They occur sometimes. If they are a regular, they might point to a problem. OK, thanks. The reason I noticed them is that they were not regular. For the record, I never saw them before upgrading to LilyDev 3. Although I didn’t scrutinize the test logs every time I ran the tests, I never noticed these messages on the occasions that I did read closely. It seems that you get this message far more often if you use the `--disable-optimising' configuration option... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead with LilyDev 3
Werner LEMBERG w...@gnu.org writes: Does anyone else see a lot of “Parsed object should be dead” programming errors in the regression test logs? They occur sometimes. If they are a regular, they might point to a problem. OK, thanks. The reason I noticed them is that they were not regular. For the record, I never saw them before upgrading to LilyDev 3. Although I didn’t scrutinize the test logs every time I ran the tests, I never noticed these messages on the occasions that I did read closely. It seems that you get this message far more often if you use the `--disable-optimising' configuration option... You don't get them at all when debugging code is disabled. So far more often is sort of a euphemism. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Parsed object should be dead with LilyDev 3
Does anyone else see a lot of “Parsed object should be dead” programming errors in the regression test logs? — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Parsed object should be dead
I'm getting a lot of: programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers from current master. Is anyone else having this problem? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead
m...@apollinemike.com m...@apollinemike.com writes: I'm getting a lot of: programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers from current master. Is anyone else having this problem? I have not gotten lots of it, but I _did_ get one on the graphviz stuff. What you are seeing (as well as the graphviz report) is likely connected with commit e9f23376b8bac1ae6b776d944469712c983e844c Author: David Kastrup d...@gnu.org Date: Wed Mar 21 19:57:46 2012 +0100 Issue 2425: Don't reload initialization files when processing multiple files This significantly speeds up processing of multiple files per session, but has some more potential for bleedover between files. Bleedover can occur when data structures set up by init.ly (and the loaded files) in the parser module before calling the main file are modified in-place. init.ly caters for the known cases: some hash tables modified by user commands are cleared at the start of a new pass, and output definitions are cloned rather than reused from the first load of init.ly. One problem might be be that parsed objects should be dead messages might more easily persist beyond the file actually causing the problem. Can you check whether this is what you are seeing (namely the messages starting with one particular file, and then triggering for every remaining file in the session)? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead
David Kastrup d...@gnu.org writes: m...@apollinemike.com m...@apollinemike.com writes: I'm getting a lot of: programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers from current master. Is anyone else having this problem? I have not gotten lots of it, but I _did_ get one on the graphviz stuff. What you are seeing (as well as the graphviz report) is likely connected with commit e9f23376b8bac1ae6b776d944469712c983e844c Well, I just investigated some more, and I _should_ have been seeing a lot more, actually. Those messages are generated for object types that have an ASSERT_LIVE_IS_ALLOWED() in their mark procedure since they are not supposed to survive the existence of their parser. The whole point of my commit, however, is to let some objects (like context definitions and context mods) travel from the first initialization run into the next session. I'll have to see whether I can come up with something that makes an exception for the saved init data. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead
m...@apollinemike.com m...@apollinemike.com writes: I'm getting a lot of: programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers from current master. Is anyone else having this problem? URL:http://code.google.com/p/lilypond/issues/detail?id=2443 I would tend to push this to staging reasonably fast once it passes the tests. No idea why this would not have been more conspicuous. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead
On Mon, May 30, 2011 at 8:08 PM, m...@apollinemike.com m...@apollinemike.com wrote: Hey all, I've been getting this from LilyPond recently: programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers Is anyone else getting this too? All typesetting, translation and music scheme objects are created in the context of a .ly file. That means that between processing two files, none of those should exist at all. If they do, you are probably persisting references to them in the wrong place, ie. some sort of global list or table. it's very well possible that the check for this is ony switched on in debugging, but it is an error in any event. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead
Hi Mike, On Mon, May 30, 2011 at 4:08 PM, m...@apollinemike.com m...@apollinemike.com wrote: I've been getting this from LilyPond recently: programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers This usually means that there is a memory leak happening somewhere. Is anyone else getting this too? About a month ago (last time I compiled LilyPond), I did not see it. This was after compiling with --disable-optimising. Do you recall when you started seeing the programming error? Regards, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead
On May 31, 2011, at 6:23 AM, Werner LEMBERG wrote: I've been getting this from LilyPond recently: programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers Is anyone else getting this too? I'm getting this all the time if I build with --disable-optimising. It seems to be harmless. Fair enough - thanks! ~Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Parsed object should be dead
Hey all, I've been getting this from LilyPond recently: programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers Is anyone else getting this too? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Parsed object should be dead
I've been getting this from LilyPond recently: programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers Is anyone else getting this too? I'm getting this all the time if I build with --disable-optimising. It seems to be harmless. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
