Re: [Denemo-devel] Denemo sporadic crash on startup.

[Richard Shann]

On Thu, 2013-05-16 at 14:39 +0200, Éloi Rivard wrote:
> 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 ?

I have seen this discussed, for this code as we have it certainly not.
There are many things allocated which the program needs until death and
it is only of benefit to valgrind and friends to de-allocate them before
exiting; it would take longer to exit and add quite a bit of code and
(certainly in our case) a lot of complexity.

> 
> You can use any library with valgrind, even those which contain memory
> leaks, but it will pollute the output with error you cannot fix.

exactly, it is this that makes it difficult to use valgrind.

>  However you can recognize leaks produced by your code, and leaks
> produced by some libraries.

Memory leaks are not serious problem, apart from occasions when they are
in some continuously running code, (e.g. the draw routine). We actually
have an enormous source of memory leak - the entire undo which resorts
to snapshotting the entire denemo data structure on many operations and
it is all leaked. Not that I'm advocating not bothering with
deallocating everything as close to the allocation as possible, even
just for a few bytes; someone will fix Undo/Redo sometime, and we don't
want a whole heap of other leaks scattered all over.

Richard


> 
> 
> 
> 2013/5/16 Éloi Rivard <address@hidden>
>         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 <address@hidden>
>                 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
>                 > address@hidden
>                 > https://lists.gnu.org/mailman/listinfo/denemo-devel
>                 
>                 
>                 
>                 _______________________________________________
>                 Denemo-devel mailing list
>                 address@hidden
>                 https://lists.gnu.org/mailman/listinfo/denemo-devel
>                 
>         
>         
>         
>         
>         -- 
>         Éloi Rivard - address@hidden
>                 
>         « On perd plus à être indécis qu'à se tromper. »
>         
> 
> 
> 
> -- 
> Éloi Rivard - address@hidden
>         
> « On perd plus à être indécis qu'à se tromper. »
>