I have fixed this bug. I think it would only have affected 64 bit machines - there was no prototype for a function returning a pointer, instead the return value was cast to a pointer, so when the pointer was too large it crashed... Richard
On Sun, 2014-03-23 at 17:31 +0000, Richard Shann wrote: > Ha! > I was just entering a sonata by Cannabich and it got to an A# which it > sounded on the organ, and found that indeed it had entered B-flat. > So then I remembered that I had just been writing of the dangers of > using the Modulation Wheel to change the set of sharps and flats (the > "enharmonic set"). > So I saved the score and upped the modulation wheel and bingo! it > segfaulted > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004cac8b in scheme_output_midi_bytes (input=0x44af220) > at ../../denemo/src/scheme-callbacks.c:4316 > 4316 for (i = 0, next = bytes; *next; next++) > (gdb) call gtk_main() > > the call to gtk_main() brought the program back to life. > > So, it seems this may be a fairly reliable way of triggering the bug. > Not one that could be automated however. > For now, stick to the buttons in the MIDI-in control panel or the > Input->MIDI menu for changing the enharmonic set. > > Any threading experts who can give advice on how to debug this - please > do! > > Richard > > On Sun, 2014-03-23 at 15:11 +0000, Richard Shann wrote: > > On Sun, 2014-03-23 at 09:41 -0500, Jeremiah Benham wrote: > > > I may be a bit confused. I thought this was all dependant upon how the > > > modwheel is set on the midi controller. > > > > Well, it doesn't matter how you last left the mod wheel - only changes > > to the mod wheel that you make after starting Denemo are registered. > > > > > When I do midi input I put the modwheel half way if I was in the key > > > of c and then move it up if I start to see flats when sharps are > > > expected and visa versa. I was not sure if that is how it is supposed > > > to work but I think I remember Richard talking about this once so I > > > tried it and it worked. > > > > yes, the default callback for the mod wheel does exactly that. I didn't > > mention it because there is a threading bug with audio output which > > makes it crash on occasions. (It makes notes of different pitches to let > > you know which range of sharps/flats you have set, higher ones for > > sharper ranges). > > > > In fact I recently had this threading bug bite me while entering > > figured bass by MIDI filter, which also uses a timer to turn off a midi > > note. I discovered something remarkable: as I was running under gdb the > > segfault from the threading bug left me at the gdb prompt. I executed > > the following: > > > > call gtk_main() > > > > this also returned me to the prompt (the note was still playing) but > > after a couple more invocations the program was running again and I > > could save my work. I didn't write to the list about this yet, as I > > don't want to give the impression that this is something a typical user > > is likely to encounter, but it is a serious worry. I have been over the > > threading code, as best I can and did not see where the trouble lay. > > The crash occurs in the function > > > > scheme_output_midi_bytes() > > > > where the data are nonsensical - it is in a timer callback to turn of a > > note that has been started earlier. > > > > If anyone can review the code to see where the threading bug arises I > > would sleep easier at night. > > > > Richard > > > > > > > > > > > > _______________________________________________ > > Denemo-devel mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/denemo-devel > > > > _______________________________________________ > Denemo-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/denemo-devel _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
