lily on ia64

[Juergen Reuter]

Hi,

still trying to compile and run lily on ia64, I have to report some
problems/bugs that we probably should try to fix.

Problem 1:
==========

First of all, compiling stops quite early with the following message:



In file included from /usr/include/signal.h:324,
                 from /usr/include/sys/ucontext.h:23,
                 from
/export/home/reuter/usr/include/libguile/continuations.h:49,
                 from /export/home/reuter/usr/include/libguile.h:63,
                 from out/config.h:79,
                 from include/libc-extension.hh:16,
                 from string.cc:22:
/usr/include/ucontext.h:32: `ucontext_t' was not declared in this scope
/usr/include/ucontext.h:32: `__ucp' was not declared in this scope
/usr/include/ucontext.h:32: warning: `getcontext' initialized and
declared `extern'
/usr/include/ucontext.h:35: parse error before `*'
/usr/include/ucontext.h:39: `ucontext_t' was not declared in this scope
/usr/include/ucontext.h:39: parse error before `,'
/usr/include/ucontext.h:48: `ucontext_t' was not declared in this scope
/usr/include/ucontext.h:48: `__ucp' was not declared in this scope
/usr/include/ucontext.h:48: `__func' was not declared in this scope
/usr/include/ucontext.h:48: parse error before `)'
/usr/include/ucontext.h:48: warning: `makecontext' initialized and
declared `extern'
/usr/include/ucontext.h:48: variable or field `makecontext' declared
void
/usr/include/ucontext.h:48: initializer list being treated as compound
expression


Ok, I think this is not a bug in lily, but rather either in guile or the
ia64 include headers.  Part of the problem is described in
<sys/ucontext.h>:


/*
 * These are here mostly for backwards compatibility with older Unices.
 * IA-64 Linux does not distinguish between "struct sigcontext" and
 * "ucontext_t" as all the necessary info is inside the former.
 */


But the core reason is that <libguile/continuations.h>
includes <sys/ucontext.h> which includes <signal.h>, which includes
<ucontext.h>, which includes <sys/ucontext.h> and immediately afterwards
uses ucontext_t which is defined in <sys/ucontext.h> *behind* the
inclusion of <signal.h>.  So, if <sys/ucontext.h> is included *before*
<signal.h>, the "#ifndef _XXX_H #define _XXX_H #endif" construct will
prevent <ucontext.h> from including ucontext_t in <sys/ucontext.h>.

So, the solution is in <libguile/continuations.h> to include <signal.h>
before (or, even better, just instead of) <sys/ucontext.h>, which is
anyway an ungly hack.  Given this error in current versions of Guile, the
workaround for lily is to include <signal.h> in
flower/include/libc-extension.hh before including "config.h".

BTW, do you think this is a Guile bug or rather a bug in the headers of
the ia64 headers of the kernel?


Problem 2:
==========

After fixing problem 1, the lily binary compiles but immediately dies with
a segmentation fault when it is first invoked during "make all".  I
tracked this down to the fact that in String_handle::down (), data == 0.
Putting some printf () into the constructors and destructor and looking at
the value of "this", it looks like the destructor is called more than once
upon a single object instance (how can that happen????).

Anyway, I looked at flower/{include/,}string*, and at least found a few
things that I find worth mentioning:

* Since all the code is inlined, it is hard to debug: (i) gdb prints the
  location of the inlined code, but not where it is inlined.  (ii) If you
  change just a single line of the inlined code, you have to fully
  recompile lily, because this is included from almost all cc files.
  (iii) Putting a couple of printf's into the *.icc files slowed down
  compiling lily from roughly 12 minutes to roughly 27 minutes on my
  Dual 500 MHz PIII machine.  Obviously, gcc compiles inlined code
  extremely slow.  Waiting another 27 minutes for changing just a single
  line of code is a pain!

  I wonder, if inlining is really necessary here.  From tracing a little
  bit, I found that a lot of time is spent in allocating and freeing empty
  String_data objects.  I guess this is much more a bottleneck than not
  inlining this stuff, considering that inlining makes debugging extremely
  hard.

* "if (! (--data->references)) delete data; data = 0;" -- this looked
  in the first place to me as if you forgot to put a pair of braces {}
  around the two statements behind the if condition.  Having a deeper
  look, I think it is correct to always set data to 0, regardless of the
  test.  This should be reflected by proper text layout, and may be even a
  comment in this special case.

* The names of some instance variables end with "_"; others do not (e.g.
  "references", "data").  This should be more constistent.

* Maybe rename "references" into "refcount_".

* "up ()" and "down ()" are really misleading names.  How about "link_to
  ()" and "unlink ()"?  "copy ()" actually unlinks and copies, so how
  about "unlink_and_copy ()"?

* string-data.icc: String_data::setmax (int j): "delete data_byte_;" ->
  "delete[] data_byte;"

* String_handle::String_handle () and String_handle::String_handle
  (String_handle const & src): for each constructor, I would suggest to
  initialize all pointer instance variables such as data to e.g. 0 before
  calling any method such as "up (...)".  Otherwise, you may be easily
  trapped (like me, when I stumbled over the value of this variable) when
  debugging or changing the code of such methods.

To get further, I put the following code to the beginning of
String_handle::down ():

  if (!data)
    {
      printf("programming_error: String_handle::down (): (data == 0)\n");
      return;
    }

With this code, lilypond runs much further, until it sometimes crashes at
a different place (see next problem).


Problem 3:
==========

Lily often crashes with a segmentation fault in the destructor of Array.
It turns out that very often array_==0 when entering the destructor.

Any idea what's going wrong here?

Greetings,
Juergen