denemo-devel
[Top][All Lists]
Advanced

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

Re: [Denemo-devel] Denemo broken ....


From: R. Mattes
Subject: Re: [Denemo-devel] Denemo broken ....
Date: Wed, 3 Aug 2011 18:45:29 +0200

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
address@hidden




reply via email to

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