David Kastrup <d...@gnu.org> writes:
> Graham Percival <gra...@percival-music.ca> writes:
>
>> On Wed, Aug 03, 2011 at 07:55:38PM +0200, David Kastrup wrote:
>>> dak@lola:/usr/local/tmp/lilypond/out/lybook-testdb$ for i in `cat
>>> /usr/local/tmp/lilypond/out/lybook-testdb/snippet-names--1980013010.ly`;do
>>> ../bin/lilypond $i || { echo $i; break; } ;done
>>
>> Cute!
>>
>>> Renaming input to: `tie-direction-manual.ly'
>>> Interpreting music...
>>> Preprocessing graphical objects...throw from within critical section.
>>> Aborted (core dumped)
>>
>> Believe it or not, I consider this a positive development --
>> that's the same error message that Frederico was getting in the
>> build, but it couldn't be reproduced easily.
I get it frequently enough at the moment to not be able to do any useful
tests. It does not occur with optimization, it does not occur every
run, and it occurs in different files depending on the computer's mood.
Yesterday I was able to reproduce it in the debugger, today I can only
do post-mortem debugging.
> #2 0x006252ae in abort () from /lib/i386-linux-gnu/libc.so.6
> #3 0x001cce9c in scm_ithrow () from /usr/lib/libguile.so.17
> #4 0x00160a94 in scm_error_scm () from /usr/lib/libguile.so.17
> #5 0x00160b31 in scm_error () from /usr/lib/libguile.so.17
> #6 0x00160e3a in scm_wrong_type_arg () from /usr/lib/libguile.so.17
> #7 0x00193d1a in scm_sum () from /usr/lib/libguile.so.17
> #8 0x00173160 in scm_gc_protect_object () from /usr/lib/libguile.so.17
> #9 0x08261c0c in get_staff_symbol (me=0x84d9318)
> at staff-symbol-referencer.cc:53
Well, this occurs at
SCM st = me->get_object ("staff-symbol");
But that is more or less a red herring since it occurs when memoizing
staff-symbol. The code path is (simplified)
({ \
static SCM cached; \
/* We store this one locally, since G++ -O2 fucks up else */ \
SCM value = cached; \
{ \
if (!cached) \
value = cached = scm_gc_protect_object (scm_from_locale_symbol
("staff-symbol"))
} \
})
It throws in scm_gc_protect_object in the code
509 SCM
510 scm_gc_protect_object (SCM obj)
511 {
512 SCM handle;
513
514 /* This critical section barrier will be replaced by a mutex. */
515 /* njrev: Indeed; if my comment above is correct, there is the same
516 critsec/mutex inconsistency here. */
517 SCM_CRITICAL_SECTION_START;
518
519 handle = scm_hashq_create_handle_x (scm_protects, obj, scm_from_int (0));
520 SCM_SETCDR (handle, scm_sum (SCM_CDR (handle), scm_from_int (1)));
521
522 protected_obj_count ++;
523
524 SCM_CRITICAL_SECTION_END;
525
526 return obj;
527 }
And it throws because scm_sum adds incompatible types. Which basically
can only happen if the data structures are borked, like when
scm_protects is not a hash table or has been collected, or the
conservative garbage collector misses protecting some of the involved
properties. It is entirely more likely that the data structures of the
garbage collector have been clobbered before getting to this code point.
> #10 Staff_symbol_referencer::get_staff_symbol (me=0x84d9318)
> at staff-symbol-referencer.cc:48
> #11 0x0813fdcd in Ledger_line_spanner::set_spacing_rods (smob=0x0)
> at ledger-line-spanner.cc:130
> #12 0x0016c766 in scm_apply () from /usr/lib/libguile.so.17
> #13 0x0016dfd0 in scm_call_1 () from /usr/lib/libguile.so.17
> #14 0x08121f55 in Grob::try_callback_on_alist (this=0x84d9318,
> alist=0x84d9348, sym=0xb5f4cd50, proc=0xb7b65be8) at grob-property.cc:227
> #15 0x081220b2 in Grob::internal_get_property (this=0x84d9318, sym=0xb5f4cd50)
> at grob-property.cc:184
> #16 0x08281953 in System::pre_processing (this=0x8596518) at system.cc:423
> #17 0x081d4493 in Paper_score::process (this=0x856f6a8) at paper-score.cc:141
[...]
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
