Re: [Denemo-devel] Denemo sometimes hangs (crashes) on quit

[Richard Shann]

On Tue, 2015-10-27 at 10:21 +0100, Andreas Schneider wrote:
> Am 27.10.2015 um 09:44 schrieb Richard Shann:
> >> Yes, this is with MIDI hardware attached (my master keyboard), and I'm
> >> using the latest git version (I do not know how to swtich to the release
> >> candidate in git).
> > well, no need at the moment as they are the same - we are in code freeze
> > now for the release.
> >>  It returned to the (gdb) prompt (that is, the prompt
> >> appeared when pressing the return key as many text was in the console
> >> before). 
> > This returning to the prompt when pressing the Return key is something I
> > also see quite often, I've not been sure that it is an indicator of a
> > crash during the termination of the Denemo process, I think perhaps not,
> > as that should be accompanied by a message from GDB about the signal
> > received (e.g. SEGFAULT ...).
> > 
> > 
> >> However, I have also experienced cases where I had to hit
> >> ctrl-C to get the (gdb) prompt.
> > 
> > That would be the process hanging (ie repeatedly looping over some
> > section of code) and that would indicate a fault in the process
> > termination. I can only guess that the thread code is not stopping
> > correctly and something ends up waiting for something else - I think
> > that would result in some (fairly harmless) zombie process or something
> > when run outside gdb. Can anyone who regularly uses Denemo on a
> > GNU/Linux system say whether they notice anything strange on exit when
> > not run under gdb control?
> > 
> > I think this will have to wait the arrival on the Denemo team of fresh
> > talent! It doesn't seem to be a serious nuisance, and perhaps doesn't
> > even happen on Windows where most users are. (Please speak up Windows
> > users if you know differently!)
> 
> What I forgot to mention is that the Denemo windows are still there, but
> do not respond anymore. That is, when running outside gdb, Denemo just
> stops to respond on File > Quit, but all windows stay there (but are not
> redrawn of course).

Right, that is something hanging e.g. two threads waiting for each other
before stopping. I gather that debugging threads is generally more
difficult than looking at the code to find dangerous calls, (though of
course that needs someone with a good knowledge of the correct use of
the threading libaries).

Richard