bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 1997 in lilypond: segfault in tablature-negative-fret.ly


From: lilypond
Subject: Re: Issue 1997 in lilypond: segfault in tablature-negative-fret.ly
Date: Sun, 27 Nov 2011 10:57:43 +0000


Comment #15 on issue 1997 by address@hidden: segfault in tablature-negative-fret.ly
http://code.google.com/p/lilypond/issues/detail?id=1997

Bad news.

void
Tab_staff_symbol_engraver::acknowledge_staff_symbol (Grob_info gi)
{
  int k = scm_ilength (get_property ("stringTunings"));
  if (k >= 0)
    gi.grob ()->set_property ("line-count", scm_from_int (k));
}

#ifndef NDEBUG
/*
  TODO: include modification callback support here, perhaps
  through intermediate Grob::instrumented_set_property( .. __LINE__ ).
 */
#define set_property(x, y) instrumented_set_property (ly_symbol2scm (x), y, __FILE__, __LINE__, __FUNCTION__)
#else
#define set_property(x, y) internal_set_property (ly_symbol2scm (x), y)
#endif

#define ly_symbol2scm(x)                                                \
  ({                                                                    \
    static SCM cached;                                                  \
    /* We store this one locally, since G++ -O2 fucks up else */        \
    SCM value = cached;                                                 \
    if (__builtin_constant_p ((x)))                                     \
      {                                                                 \
        if (!cached)                                                    \
          value = cached = scm_gc_protect_object (scm_or_str2symbol (x)); \
      }                                                                 \
    else                                                                \
      value = scm_or_str2symbol (x);                                    \
    value;                                                              \
  })

void
Grob::internal_set_property (SCM sym, SCM v)
{
  internal_set_value_on_alist (&mutable_property_alist_,
                               sym, v);

}



(gdb) disass
Dump of assembler code for function Tab_staff_symbol_engraver::acknowledge_staff_symbol(Grob_info):
   0x082b0a60 <+0>:       push   %ebx
   0x082b0a61 <+1>:       sub    $0x18,%esp
   0x082b0a64 <+4>:       mov    0x83f3f40,%eax
   0x082b0a69 <+9>:       mov    0x20(%esp),%ebx
   0x082b0a6d <+13>:      test   %eax,%eax
0x082b0a6f <+15>: je 0x82b0ac0 <Tab_staff_symbol_engraver::acknowledge_staff_symbol(Grob_info)+96>
   0x082b0a71 <+17>:      mov    %eax,0x4(%esp)
   0x082b0a75 <+21>:      mov    %ebx,(%esp)
0x082b0a78 <+24>: call 0x82d5050 <Translator::internal_get_property(scm_unused_struct*) const>
   0x082b0a7d <+29>:      mov    %eax,(%esp)
   0x082b0a80 <+32>:      call   0x804e650 <address@hidden>
   0x082b0a85 <+37>:      test   %eax,%eax
0x082b0a87 <+39>: js 0x82b0ab8 <Tab_staff_symbol_engraver::acknowledge_staff_symbol(Grob_info)+88>
   0x082b0a89 <+41>:      mov    %eax,(%esp)
   0x082b0a8c <+44>:      call   0x804e2d0 <address@hidden>
   0x082b0a91 <+49>:      mov    %eax,%ebx
   0x082b0a93 <+51>:      mov    0x83f3f44,%eax
   0x082b0a98 <+56>:      test   %eax,%eax
0x082b0a9a <+58>: je 0x82b0ae0 <Tab_staff_symbol_engraver::acknowledge_staff_symbol(Grob_info)+128>
   0x082b0a9c <+60>:      mov    %ebx,0x28(%esp)
   0x082b0aa0 <+64>:      mov    %ebx,0x20(%esp)
   0x082b0aa4 <+68>:      mov    %eax,0x24(%esp)
   0x082b0aa8 <+72>:      add    $0x18,%esp
=> 0x082b0aab <+75>:   pop    %ebx
0x082b0aac <+76>: jmp 0x812e760 <Grob::internal_set_property(scm_unused_struct*, scm_unused_struct*)>

Function arguments to internal_set_property (starting with this) are
at 0x20(%esp) and following.

So the first argument (after `this') is the memoized string
"line-count".  So far, so good.  The second argument is the converted
value of k.  So far, so nice.  However, `this' (the self-pointer) is
_also_ set to value of k rather than the actual grob.

WTF?!?

Apparently GCC-4.6.0 gets confused about what it keeps in which
register.

Does anybody have a reasonable idea how we should be dealing with
compiler problems?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]