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 _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
