Dave;
> Sorry I should have posted more info - this is how I debug fluxus for > memory leaks, but it should also detect buffer overruns etc: > > valgrind --vex-iropt-precise-memory-exns=yes --leak-check=full > --show-reachable=yes --error-limit=no fluxus > > Thanks, that worked a lot better. I'm happy to report that once it was up and running and I was testing the new and tweaked scratchpad functionality I couldn't get valgrind to report memory errors on any of the permutations I tried. I especially tested various ways of deleting, cutting and "over-pasting" expressions and parts of text as those seemed most likely to cause issues. It's not perfect though; I was getting a few uses of uninitiated values of size 4, something that we have a LOT of, according to Valgrind, and nearly all of them somehow involve "scheme_do_eval". I got those notices at simple cursor movements, not as any of the tested commands (I'm not sure why cursor movements would need scheme evaluation with the current setup). I also noted that there is still a little bug in that pasting will move the cursor yet won't updated the "desired x position" which leads to counter-intuitive x positions of the cursor when moving up or down after pasting (and probably cutting as well). I also noticed that [ctrl+a] would sometimes not select all text doing things like taking the cursor or the end of a different line as the end point of the selection. That behaviour was non-deterministic as far as I could tell and I was unable to repeat those findings outside of Valgrind. I'm slightly annoyed by that. So yes, it's not perfect but it doesn't seem to leak memory either which I suppose is the good news. Next I'm going to try to find all indirect causes of cursor movement and see whether those need to set a new "desired x position". That should be a improvement and I think that only means writing to a single variable so it shouldn't further complicate the issue. Yours, Kas.
