Segmentation fault during `make check'

2021-03-15 Thread Michael Käppler

Hi all,
I encountered a segmentation fault that happens sporadically during a
'make check' run.
See https://gitlab.com/lilypond/lilypond/-/merge_requests/683 for some
context.

It is not reproducable with a specific snippet, but I could reproduce it
on top of a failed
'make check' run by running the 'lilypond' command that failed.

Unfortunately, it seems somehow related to optimization, because the
identical setup
with an unoptimized lilypond binary (compiled in a different tree from
same 'master') does
not fail. Pretty hard to track it down...

I do not know if the stack trace of the optimized binary is useful, but:

#0  0x7780aa1c in scm_dapply (proc=0x404, arg1=,
args=0x7fffec751010)
    at eval.c:4989
#1  0x55669b84 in
Engraver::internal_make_grob(scm_unused_struct*, scm_unused_struct*,
char const*, int, char const*) (this=,
symbol=0x72fc4920, cause=cause@entry=0x404, file=0x558d2848
"/home/michael/lilypond/lily/paper-column-engraver.cc", line=73,
fun=0x558d2f28 
"make_columns") at /home/michael/lilypond/lily/engraver.cc:146
#2  0x55669ea7 in
Engraver::internal_make_column(scm_unused_struct*, char const*, int,
char const*) (this=, x=, file=, line=, fun=) at
/home/michael/lilypond/lily/engraver.cc:166
#3  0x55758b9e in Paper_column_engraver::make_columns()
(this=this@entry=0x561a59b0)
    at /home/michael/lilypond/lily/paper-column-engraver.cc:73
#4  0x55758e3d in Paper_column_engraver::initialize()
(this=0x561a59b0)
    at /home/michael/lilypond/lily/paper-column-engraver.cc:82
#5  0x5584c317 in Callbacks::trampoline(scm_unused_struct*) (target=) at
/home/michael/lilypond/lily/include/callback.hh:114
#6  0x7780ad86 in scm_dapply (proc=0x70f7a220,
arg1=0x7fffec7ad290, args=0x404) at eval.c:5019
#7  0x5584b5b1 in translator_each(scm_unused_struct*,
scm_unused_struct*) (method=, list=) at
/home/michael/lilypond/lily/translator-group.cc:45
#8  0x5584b5b1 in recurse_over_translators(Context*,
scm_unused_struct*, scm_unused_struct*, Direction)
(c=c@entry=0x56573340, ptr=0x70f7a220,
tg_ptr=tg_ptr@entry=0x70f7a240, dir=dir@entry=DOWN) at
/home/michael/lilypond/lily/translator-group.cc:211
#9  0x5584b9d2 in
Translator_group::create_child_translator(scm_unused_struct*)
(this=, sev=) at
/home/michael/lilypond/lily/translator-group.cc:169
#10 0x5584c3b5 in Callbacks::trampoline(scm_unused_struct*,
scm_unused_struct*) (target=, ev=)
    at /home/michael/lilypond/lily/include/callback.hh:124
#11 0x7780afaf in scm_dapply (proc=0x70f804a0,
arg1=0x7fffece1cfc0, args=0x7fffec7adbf0)
    at eval.c:5021
#12 0x55652627 in Listener::listen(scm_unused_struct*)
(ev=, this=)
    at /home/michael/lilypond/lily/include/listener.hh:108
#13 0x55652627 in
Smob_base::smob_trampoline<&Listener::listen>(scm_unused_struct*,
scm_unused_struct*) (self=, arg1=)

Maybe related to garbage collection?
Does anyone have a clue?

Michael



Re: Segmentation fault during `make check'

2021-03-15 Thread Michael Käppler

Am 15.03.2021 um 12:03 schrieb Michael Käppler:


Unfortunately, it seems somehow related to optimization, because the
identical setup
with an unoptimized lilypond binary (compiled in a different tree from
same 'master') does
not fail. Pretty hard to track it down...


Ouch, I cannot reproduce it even with a freshly compiled lilypond from
same master, with
same 'configure' settings. (--enable-checking)
The binarys, however, are not byte-identical. I though we managed some
time ago to have
completely reproducable builds?

Luckily I still have the failing binary here...

Michael



guile libraries

2021-03-15 Thread Al Rice

Greetings,

My name is Al.  I am a retied design engineer.  15 years embedded in 
assembly followed by 20 in the Windows environment programming C and its 
derivatives.  Since retiring I moved all my development machines to 
linux and started looking at opensource projects to keep my hand in.  I 
am also an aspiring musician and have used Finale, MuseScore and 
lilypond with Frescobaldi to a great extent.


I am attempting to compile lilypond 2.22 on xubuntu 20.04 using "make 
all".  I get the error:


/usr/bin/ld: cannot find -lguile

Should be a simple thing to set a path to the guile 1.8 libraries - 
but I cannot find them, either.


Would someone be so kind as to offer some advice on compiling lilypond?

Thanks,

Al





Re: guile libraries

2021-03-15 Thread Benkő Pál
There's a quick path for an underperforming lilypond: sudo apt install
guile-2.2-dev.  The slow path for good performance is installing
guile-1.8 from its git repository, which I never did.

Al Rice  ezt írta (időpont: 2021. márc. 15., H, 18:36):
>
> Greetings,
>
> My name is Al.  I am a retied design engineer.  15 years embedded in
> assembly followed by 20 in the Windows environment programming C and its
> derivatives.  Since retiring I moved all my development machines to
> linux and started looking at opensource projects to keep my hand in.  I
> am also an aspiring musician and have used Finale, MuseScore and
> lilypond with Frescobaldi to a great extent.
>
> I am attempting to compile lilypond 2.22 on xubuntu 20.04 using "make
> all".  I get the error:
>
> /usr/bin/ld: cannot find -lguile
>
> Should be a simple thing to set a path to the guile 1.8 libraries -
> but I cannot find them, either.
>
> Would someone be so kind as to offer some advice on compiling lilypond?
>
> Thanks,
>
> Al
>
>
>



Re: Segmentation fault during `make check'

2021-03-15 Thread Jonas Hahnfeld
Hi Michael,

Am Montag, dem 15.03.2021 um 12:03 +0100 schrieb Michael Käppler:
> Hi all,
> I encountered a segmentation fault that happens sporadically during a
> 'make check' run.
> See https://gitlab.com/lilypond/lilypond/-/merge_requests/683 for some
> context.
> 
> It is not reproducable with a specific snippet, but I could reproduce it
> on top of a failed 'make check' run by running the 'lilypond' command that 
> failed.
> 
> Unfortunately, it seems somehow related to optimization, because the
> identical setup with an unoptimized lilypond binary (compiled in a different 
> tree from
> same 'master') does not fail. Pretty hard to track it down...

I'm confused here: Was the initial segmentation fault also on master or
with MR !683 applied?


> I do not know if the stack trace of the optimized binary is useful, but:
> 
> #0  0x7780aa1c in scm_dapply (proc=0x404, arg1=,
> args=0x7fffec751010)
>  at eval.c:4989
> #1  0x55669b84 in
> Engraver::internal_make_grob(scm_unused_struct*, scm_unused_struct*,
> char const*, int, char const*) (this=,
> symbol=0x72fc4920, cause=cause@entry=0x404, file=0x558d2848
> "/home/michael/lilypond/lily/paper-column-engraver.cc", line=73,
> fun=0x558d2f28 
> "make_columns") at /home/michael/lilypond/lily/engraver.cc:146

This is in the branch of "if (ly_is_procedure (creation_callback))",
which probably means two things:
1. It might be related to the changes in MR !683 because my
understanding is that Graphiz is the only user of ly:set-grob-creation-
callback.
2. Depending on whether you hit the fault when processing
input/regression/graphviz.ly (my understanding is you don't?), the
creation callback is not reset after a session (= an input file) ends.

Jonas


signature.asc
Description: This is a digitally signed message part


-lguile -- cannot be found [SOLVED]

2021-03-15 Thread Al Rice

OK, it looks as though hijacked a previous thread.  Sorry about that.

Although I did install the guile-2.2-dev I still get the same error:
/usr/bin/ld: cannot find -lguile

In config.make is the following line:
CONFIG_LIBS =   -lglib-2.0 -L/usr/local/lib -lguile

I solved my problem by running "locate libguile" and ended up pointing that offending line to 
"/usr/local/include" instead of "/usr/local.lib".

thanks,
Al



There's a quick path for an underperforming lilypond: sudo apt install
guile-2.2-dev.  The slow path for good performance is installing
guile-1.8 from its git repository, which I never did.

Al Rice  ezt írta (időpont: 2021. márc. 15., H, 18:36):


Greetings,

My name is Al.  I am a retied design engineer.  15 years embedded in
assembly followed by 20 in the Windows environment programming C and its
derivatives.  Since retiring I moved all my development machines to
linux and started looking at opensource projects to keep my hand in.  I
am also an aspiring musician and have used Finale, MuseScore and
lilypond with Frescobaldi to a great extent.

I am attempting to compile lilypond 2.22 on xubuntu 20.04 using "make
all".  I get the error:

/usr/bin/ld: cannot find -lguile

Should be a simple thing to set a path to the guile 1.8 libraries -
but I cannot find them, either.

Would someone be so kind as to offer some advice on compiling lilypond?

Thanks,

Al





Re: guile libraries

2021-03-15 Thread Werner LEMBERG

> I am attempting to compile lilypond 2.22 on xubuntu 20.04 using "make
> all".  I get the error:
> 
> /usr/bin/ld: cannot find -lguile
> 
> Should be a simple thing to set a path to the guile 1.8 libraries -
> but I cannot find them, either.

Most likely you have to compile guile 1.8 by yourself since it is no
longer available universally as a distribution package.  Starting with
guile's git repository as a source is probably best:

  https://git.savannah.gnu.org/cgit/guile.git/log/?h=branch_release-1-8

* Clone this repository and check out the `branch_release-1-8` branch.

* Run the `./autogen.sh` script.

* Run 

./configure --prefix=/usr/local/opt --disable-error-on-warning
make
make install

  (adjusting `--prefix` to your taste).

* Call LilyPond's `configure` script like the following.

PKG_CONFIG_PATH=/usr/local/opt/lib64/pkgconfig \
./configure ...


   Werner


Re: Segmentation fault during `make check'

2021-03-15 Thread Michael Käppler

Hi Jonas,



I do not know if the stack trace of the optimized binary is useful, but:

#0  0x7780aa1c in scm_dapply (proc=0x404, arg1=,
args=0x7fffec751010)
  at eval.c:4989
#1  0x55669b84 in
Engraver::internal_make_grob(scm_unused_struct*, scm_unused_struct*,
char const*, int, char const*) (this=,
symbol=0x72fc4920, cause=cause@entry=0x404, file=0x558d2848
"/home/michael/lilypond/lily/paper-column-engraver.cc", line=73,
fun=0x558d2f28 
"make_columns") at /home/michael/lilypond/lily/engraver.cc:146

This is in the branch of "if (ly_is_procedure (creation_callback))",
which probably means two things:

thanks for spotting this. 'creation_callback' is currently not protected
against
garbage collection, unlike the other debugging callbacks.
I will prepare a separate MR to fix this.

Michael



Re: guile libraries

2021-03-15 Thread Valentin Petzel
Hello Al,

The problem is that guile-1.8 is not supported by modern distros anymore.

I’m not sure if Ubuntu handles this well, but under Debian you can fetch the 
source code with apt-get source lilypond. (Ubuntu just uses the version 
maintained by Debian, so I think this should work out.)
This will download the source code as used by Debian, which means that it will 
come bundled with it’s own guile1.8 version. It also gives you the Makefile 
debian/rules for building and packaging.

So you can just do
apt-get build-dep lilypond
To install the dependencies needed for building, and
apt-get source lilypond
to fetch the source code.

Of course you can also try to install guile-1.8-dev from Jessie/Xenial.

Cheers,
Valentin

Am Montag, 15. März 2021, 17:54:16 CET schrieb Al Rice:
> Greetings,
> 
> My name is Al.  I am a retied design engineer.  15 years embedded in
> assembly followed by 20 in the Windows environment programming C and its
> derivatives.  Since retiring I moved all my development machines to
> linux and started looking at opensource projects to keep my hand in.  I
> am also an aspiring musician and have used Finale, MuseScore and
> lilypond with Frescobaldi to a great extent.
> 
> I am attempting to compile lilypond 2.22 on xubuntu 20.04 using "make
> all".  I get the error:
> 
> /usr/bin/ld: cannot find -lguile
> 
> Should be a simple thing to set a path to the guile 1.8 libraries -
> but I cannot find them, either.
> 
> Would someone be so kind as to offer some advice on compiling lilypond?
> 
> Thanks,
> 
> Al

signature.asc
Description: This is a digitally signed message part.


Re: guile libraries

2021-03-15 Thread Al Rice
Thanks.  I have actually managed to build the necessary 1.8 libraries 
and am now able to compile without error.


Al

On 3/15/21 3:55 PM, Valentin Petzel wrote:

Hello Al,

The problem is that guile-1.8 is not supported by modern distros anymore.

I’m not sure if Ubuntu handles this well, but under Debian you can fetch the
source code with apt-get source lilypond. (Ubuntu just uses the version
maintained by Debian, so I think this should work out.)
This will download the source code as used by Debian, which means that it will
come bundled with it’s own guile1.8 version. It also gives you the Makefile
debian/rules for building and packaging.

So you can just do
apt-get build-dep lilypond
To install the dependencies needed for building, and
apt-get source lilypond
to fetch the source code.

Of course you can also try to install guile-1.8-dev from Jessie/Xenial.

Cheers,
Valentin

Am Montag, 15. März 2021, 17:54:16 CET schrieb Al Rice:

Greetings,

My name is Al.  I am a retied design engineer.  15 years embedded in
assembly followed by 20 in the Windows environment programming C and its
derivatives.  Since retiring I moved all my development machines to
linux and started looking at opensource projects to keep my hand in.  I
am also an aspiring musician and have used Finale, MuseScore and
lilypond with Frescobaldi to a great extent.

I am attempting to compile lilypond 2.22 on xubuntu 20.04 using "make
all".  I get the error:

/usr/bin/ld: cannot find -lguile

Should be a simple thing to set a path to the guile 1.8 libraries -
but I cannot find them, either.

Would someone be so kind as to offer some advice on compiling lilypond?

Thanks,

Al




Outstanding Issues

2021-03-15 Thread Al Rice

Is there a list of outstanding issues for LilyPond?





Re: Outstanding Issues

2021-03-15 Thread Carl Sorensen


On 3/15/21, 5:09 PM, "lilypond-devel on behalf of Al Rice" 
 wrote:

Is there a list of outstanding issues for LilyPond?

https://gitlab.com/lilypond/lilypond/-/issues

There are a lot of them!

Carl