rshann_> valgrind is very difficult to make use of in this situation - it would only work if you were writing a program in which you de-allocate all memory before exiting, including using only libraries that do that. Hum. Ain't memory de-allocation before exiting the good practice ? You can use any library with valgrind, even those which contain memory leaks, but it will pollute the output with error you cannot fix. However you can recognize leaks produced by your code, and leaks produced by some libraries.
2013/5/16 Éloi Rivard <[email protected]> > This is weird, I just test your script and launched Denemo 500 times > without crash. > I can't test on GTK2 because Fedora 18 miss some packages (evince). Could > you also test in GTK3 ? > What optimization options have you enabled ? > > I ran a checkcpp two days ago and it told me some potential leaks, I'll > try to look at that when I have some time. I would like to play with > valgrind too. Did you usually use those tools ? > > > 2013/5/15 Richard Shann <[email protected]> > >> I am fairly sure this started about May 5th, but unfortunately the >> commits about this time make denemo un-compilable, so it is difficult to >> test. >> My suspicion is that it is this change: >> >> commit b56cad8dba8df69afcdf5d32afd1c665d011d3b9 >> added an external program to generate commands.c >> >> I think it causes a memory corruption which then shows itself in >> unpredictable ways. >> >> Richard >> >> >> On Wed, 2013-05-15 at 17:21 +0100, Richard Shann wrote: >> > I have noticed a crash that occurs occasionally on start up. >> > I have devised the following script >> > >> > echo "COUNTER is " $1 && ./denemo -a "(d-Quit)" && COUNTER=$1 && let >> COUNTER=COUNTER+1 && [ $COUNTER -le 500 ] && run_forever.sh $COUNTER fi >> > >> > You need to have this in the path, and to have the version of denemo you >> > are testing in the cwd. >> > >> > This runs Denemo up to 500 times. Run on recent versions of Denemo it >> > crashes after a certain number of iterations (I have seen it last for >> > 216, other times just a few dozen or less). >> > >> > The crash is either a segmentation fault, or sometimes an exit by the >> > memory allocator complaining of corruption. The call stack in this case >> > goes back to a scheme error callback. >> > >> > I have run the test on the latest release without it crashing (I had no >> > limit, and it got up between 600 and 1000 iterations and then my O/S >> > seized up - I was running the system monitor and it showed swap starting >> > to get used up, then most everything froze and I lost control over mouse >> > and keyboard - disk activity was continuing and I forced a shut down >> > after a while). >> > >> > With it happening so rarely this will be difficult to pin down to a >> > particular check-in. I think it goes back a couple of weeks or so at >> > least. >> > >> > If anyone cares to run the test please let me know what you find - I am >> > running gtk2 and guile-1.8.7 >> > >> > 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 >> > > > > -- > Éloi Rivard - [email protected] > > « On perd plus à être indécis qu'à se tromper. » > -- Éloi Rivard - [email protected] « On perd plus à être indécis qu'à se tromper. »
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
