The observations known thus far do not yet really sum up for me into something which I fully understand. Of course, the diagnostic was helpful, insofar it seems to point into the quite regular sound processing code, and not directly involve one of the new instance / gui / init functions.
But I'm still cautious to jump to any conclusions. Thus my question if the crash can be reproduced with the minimal changeset on branch "kristian_1" (to rule out that some mistake in the code-clean-up is the cause) Does the Crash happen always at precisely the same point? Does the Stacktrace always look the same (modulo those values which can be expected to vary randomly)? Or do we rather get just /some/ Stacktrace at roughly the same time, but beyond that, more or less randomly? Does the project run under LV2? Was any GUI of any plugin ever activated? I'm asking this, because, if it is really a memory corruption, it must have been caused by something which is new on the branch. That would be the start-up of some GUI, generally the concurrent start-up of a new instance, or a push-update to an effect module or EQ graph Does the Project (and especially in the critical part) include much automation? How is this automation implemented? Midi Learn was mentioned ... so does this mean that there are parameter changes sent via MIDI -> Core If a lot of effect commands are processed, we could end up with producing more than 64 push updates before a GUI thread did consume anything. In that case, newer updates could overwrite older ones. I took that possibility into account during the design (notably the access to the data slots is protected by a mutex, there is a timeout of 500ms and a consistency check); but there may be a gap in my reasoning, leading to some kind of corruption somewhere. -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
