gdb and hanging lilypond

[Mike Solomon]

Hey all,

On my GCC-built-but-running-on-OSX lilypond, LilyPond has started to hang at 
the “Finding the ideal number of pages” stage.

I have compiled LilyPond with debugging and without optimization, but when I 
gdb it and kill the process, no meaningful stack trace is given:

My wild guess is that there’s some mix and match problem between dynamically 
linked libraries that have been compiled with clang and the executable, which 
is compiled with gcc.

In the meantime, I’m gonna try to get lilypond compiling with clang again.  I 
may just give up and get another VBox if it is too much of a hassle.

In the mean-meantime, I’ve put the cryptic gdb backtrace below.  Does anyone 
know how to try to get it to be more informative?

Cheers,
MS

MacBook-Pro-de-Mike:bidouillage mikesolomon$ sudo gdb lilypond
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin13.0.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from 
/Users/mikesolomon/devel/lilypond/build/lily/out/lilypond...done.
(gdb) run foo.ly
Starting program: /Users/mikesolomon/devel/lilypond/build/out/bin/lilypond 
foo.ly
GNU LilyPond 2.19.0
Processing `foo.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...[New Thread 0x1a0b of process 14992]

Program received signal SIGTERM, Terminated.
0x00007fff930a90de in ?? ()
(gdb) backtrace
#0  0x00007fff930a90de in ?? ()
#1  0x00007fff5fbf98b0 in ?? ()
#2  0x0000000100dff36c in ?? ()
#3  0x0000000000d444c0 in ?? ()
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

#4  0x0000000000000000 in ?? ()
(gdb)