On Wed, 03 Aug 2011 17:17:15 +0100, Richard Shann wrote > On Wed, 2011-08-03 at 14:35 +0000, Ralf Mattes wrote: > > On Wed, 03 Aug 2011 07:45:56 +0000, Ralf Mattes wrote: > > > > > Hello list, > > > > > > after a git-pull (and autoreconf -vfi) denemo builds but fails to run: > > > > > > > > Any ideas? > > > > > > > Some desperate debugging later ... > > Seems like denemo just segfaults (now: why don't I see this at the shell prompt? > > Is someone really catching signals?). > There is some doubtful looking code in main() which tries to save the > current score into a file called crashrecovery.denemo > this has never done anything useful for me, I prefer programs that do > not crash :)
Me too - but iff an application crashes I want a segfault. That way I can even get a core dump to debug after the fact. And all of that I loose just because of 'denemo_signal_handler'. I _might_ tolerate such a beast iff it would sensibly try to do something useful - but calling (memory allocating) functions like g_print or the like after tripping over a dangling pointer, stomping all over it's own heap and while tumbling down possibly messing up it's symbol table will probably cause more havoc than a segfault :-) > > Stacktrace is here: > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0xb687f730 (LWP 19947)] > > jack_output_midi_event (buffer=0xbfe7e44b "ð\177\177\b\b\003\177\177", '@' <repeats 12 times>, "÷", client_number=0, port_number=0) > > at jackmidi.c:187 > > the problem in part may be because you have enabled jack, and the > jack is not getting tested or updated regularly Too bad, I'm a jack-only person. At least for Linux jack should be the default (if not the only API by now). > > warning: Source file is more recent than executable. > > 187 DenemoScore *si = Denemo.gui->si; > > (gdb) > > > > > > Now: > > > > (gdb) print Denemo.gui > > $1 = (DenemoGUI *) 0x0 > > > > Dereferencing this like here ' DenemoScore *si = Denemo.gui->si; ' of course segfaults. > > > > BTW - why does denemo try to set/change the tuning _during startup_??? > > This looks like a bug fixed a couple of weeks back - something was being > done too early resulting in attempts to send MIDI messages too early. Hmm - this is a fresh 'git co master' / 'git pull' 'autoreconf -fvi' 'configure ...' 'make' > But perhaps you are seeing it because of trying to use Jack. The user's > preference for temperament is set up at some stage during startup, > and there is no special code (I suspect) to say don't set the tuning > if the desired temperament is equal temperament (which there should > be perhaps, since this is the default for MIDI). This happens with a clean user dir as well. > > > > #1 0x0808a9d2 in change_tuning (cents=0x81653c0) at midi.c:135 > > #2 0x0810a64f in set_tuning () at pitchentry.c:1103 > > > > That's a nuisance at least. Keep of my keyboard unless i ask you for it. > There is a preference to auto start MIDI in, this should certainly > affect what happens when your temperament preference is activated - I > think the fluid code is up to date in this respect (i.e. I don't > think it tries to output MIDI messages if there is no MIDI in hooked > up). Richard But I obviously does - no user preferences, no connection to jack and still the above stacktrace. Looking at jackmidi.c, 'static gboolean jack_server_running = TRUE;' doesn't sound like a wise thing to me. Why should this be set to true during application startup, without ever testing jackd status? -- R. Mattes - Hochschule fuer Musik Freiburg [email protected] _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
