bugDenemo - Bugs: bug #36969, Yet Another Crash with 0.9.5rc2 ...

 
 

bug #36969: Yet Another Crash with 0.9.5rc2 Windows

Submitter:  John Beattie <jabeattie>
Submitted:  Thu 26 Jul 2012 08:56:27 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  rshann
Originator Name:  Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 18 Aug 2012 07:47:38 AM UTC, comment #19: 

Fixed in git. Thank you very much for identifying and helping to track down this bug. It is still the case that the drawing routine is doing a lot a repeated processing which could be cached but my testing shows no eating of memory when cursor highlighting is on now.

Richard Shann <rshann>
Group administrator
Fri 17 Aug 2012 05:13:51 PM UTC, comment #18: 

Ok I have tracked this down. It will take a little work to fix it. It gobbles memory if there is a standalone directive in a measure that is being displayed.

Richard Shann <rshann>
Group administrator
Fri 17 Aug 2012 10:22:52 AM UTC, comment #17: 

It seems it is the drawing routine that is leaking memory. I have just fixed the highlight cursor preference bug, as this is a partial workaround. I will look for the leak.

Richard Shann <rshann>
Group administrator
Fri 17 Aug 2012 08:46:54 AM UTC, comment #16: 

I checked the figures for the test in previous comment at fairly regular intervals.
Hourly rates showed a fairly steady increase in committed memory at the rate of 1MB in just over 13 secs.
I watched it pass the 1000MB mark in just over 3 1/2 hours and then left it overnight.
In morning denemo had crashed but the Windows box saying it 'had stopped working, do you want to close?' was still up and denemo still showed in the Resource Overview. So the final figures were:
Commit 1988MB, Working Set 750 MB, shared 3 MB, Private 747 MB.
Working set & Private increased in line with Commit but dropped back down every now and again presumably swapped out to pagefile.
No Autosaves and no recovery file.
So at least we can say it is not autosave.

John Beattie <jabeattie>
Fri 17 Aug 2012 08:40:12 AM UTC, comment #15: 

I can see it now: with that fairly large file I get memory leaking steadily without autosave. I will fix the highlight cursor volatility first and assuming the problem is still there investigate further.

Richard Shann <rshann>
Group administrator
Thu 16 Aug 2012 08:59:04 PM UTC, comment #14: 

It looks like the speed that it looses memory is related to the file that is loaded. With just an empty file it is not noticable.
I have loaded "pavana Dolorosa" from the web site as a known file.
That seems to be loosing at the rate of 1MB every 12 seconds.
Last time I was monitoring the Performance graph showing TOTAL free memory. This means that the 'garbage collection' could have been the system freeing up memory from dead processes or something like that.
This time I am using the default "Resource Overview" view and monitoring denemo.exe in the memory section.
It started off with about 55 MB committed. About 25 mins later that is up to 170MB -still a long way to go before it will crash.
I have turned off autosave.
Highlight cursor is a problem. It does not stay off i.e. if you turn it off in preferences, exit denemo, then restart denemo, then Highlight cursor is ticked again. If have unticked it in this session but I don't know if it is something that happens immediately.
I have "hidden" all my scripts. Is that enough to make sure they are not doing anything? They only set header entries or embed Lilyput directives so I wouldn't have thought they would be running continuously.

John Beattie <jabeattie>
Thu 16 Aug 2012 06:33:24 PM UTC, comment #13: 

I have run denemo up on a windows vista box and started the Windows "Reliability and Performance Monitor"  program you mentioned (never knew that existed!) it shows the memory usage steady at 58040Kb (the working set figure), other conditions as for the testing I did on Debian stable.
So I don't know what to make of that. I don't think we offer any scripts that continually run scheme commands, though you could write one easily (thinking here that you may have some additional activity due to some custom scripting).


Richard Shann <rshann>
Group administrator
Thu 16 Aug 2012 06:12:20 PM UTC, comment #12: 

I have set autosave going, set the cursor highlighting, opened the scorelayout and printview windows got the print displayed and then waited for some hours without seeing any increase in memory use. (This is on Debian stable).

You mentioned Adobe plugins - Denemo is entirely free software and does not have any plugins. It can be made to launch non-free programs (e.g. png viewer or pdf viewer) but the display of pdf within Denemo is via the libevince library whose source code can be examined and instrumented to detect leaks.

Richard Shann <rshann>
Group administrator
Thu 16 Aug 2012 02:48:11 PM UTC, comment #11: 

We once had a memory leak in the draw routine which is called at every cursor flash.
But if this is being garbage collected the finger would point outside of Denemo as we have no garbage collector in Denemo, memory is freed programmatically. (In fact, the Undo system gradually eats up memory as you work, which should be fixed, but is irrelevant here I hope).
Scheme does have a garbage collector, I guess it could be that autosaving could indirectly call some scheme script. Gtk or the evince widget may invoke a garbage collector.
If you have a way of seeing whether the leak is taking place could you try turning off autosave, cursor highlighting, not opening printview window (in fact not doing anything other than starting up the program) to see if we can narrow down where the memory leak may be happening?
Meanwhile, I'll look to see if I can see such a thing on GNU/Linux.

Richard Shann <rshann>
Group administrator
Thu 16 Aug 2012 01:11:39 PM UTC, comment #10: 

I have been monitoring my machine with the Windows "Reliability and Performance Monitor" and that suggests that there is a memory leak while denemo is running. I can't tie it down any better than that as I have only course measurements.
I have 3GB of memory on my machine. After loading Denemo I have about 1.5GB free. While Denemo is running I loose about 1MB every 4 or 5 seconds. Occasionally it appears as if a garbage collector is called and memory is freed again. Sometimes this can free up several hundred MB but it is never enough to restore the system to the way it was so very slowly I loose memory.
While I have more than 1GB free, there are no problems. At some undetermined point between 500MB and 1GB free, Denemo becomes unstable and is likely to crash while saving, autosaving or displaying "Denemo Print View".
NB does "Denomo Print View" include some sort of Adobe-supplied plugin? The Adobe Acrobat X reader also becomes unstable when the memory is low and it crashes in a similar way to Print View i.e. it will display first part of new document but as soon as you touch the window with a mouse, e.g. to make window bigger, it crashes.
I suspect that all the unexplained crashes I have been seeing are indirectly caused by this memory leak. Ideally a failure to acquire memory should not cause a crash, but when you get to the stage where you have to abort an action and are unable to even inform the user, then that gets a bit tricky.

John Beattie <jabeattie>
Wed 15 Aug 2012 03:38:39 PM UTC, comment #9: 

The debug output "loop" you see is generated by the script that checks the score for common errors before printing. The message (#f Wrong type to apply ...) is a message from a scheme script indicating that the script has an error in it.
Errors in scripts should never cause an exit though as there is a trap handler set (which is what is generating that message).
The "No of displays..." message is in the signal handler which is setup via

signal (SIGSEGV, denemo_signal_handler);

in main.c, it should mean that the program tried to access memory incorrectly. It is at this point that the program tries to save the file crashrecovery.denemo which may simply cause a further crash which will then exit.

I guess you cannot reliably create this crash? Did they all involve the same file?

Richard Shann <rshann>
Group administrator
Wed 15 Aug 2012 02:36:15 PM UTC, comment #8: 

Famous Last Words.
Since last entry I have had 4 crashes with rc5 but only only with error logging on. That one an I think at least 2 of the other were when typesetting or just after.
I don't know whether this is related to the crash in this bug or the other 2 but I'll record the info here.

Stdout (I'm going to go a long way back in case 'loop' is significant)
Autosaving
p

loop

loop

loop

loop

loop

loop

loop


finished generating LilyPond
(#f Wrong type to apply: ~S (#t) #f)
misc-error

(#f Wrong type to apply: ~S (#t) #f)
misc-error

(#f Wrong type to apply: ~S (#t) #f)
misc-error

loop

(At this point there are over 800 'loop's) followed by

Printname this time denemoprint8
pos 2
No of displays : 1


Stderr doesn't show anything of interest. It is exactly the same as the previous print attempt earlier in the session. Both print attempts said they failed, both created pdf files but only the last one crashed. The last few lines of stderr are:

[C:/Program Files/Denemo/usr/share/lilypond/current/ps/lilyponddefs.ps]
Converting to `./denemoprint8.pdf'...
Invoking `gs -dNOSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=./denemoprint8.pdf -c.setpdfwrite -fdenemoprint8.ps'...
GPL Ghostscript 8.70 (2009-07-31)

Copyright (C) 2009 Artifex Software, Inc.  All rights reserved.

This software comes with NO WARRANTY: see the file PUBLIC for details.

WARNING: /Unicode /Decoding resource is not accessible but it is useful for generating ToUnicode CMap.

]
error: failed files: "C:\\Users\\jab\\AppData\\Local\\Temp\\Denemo-1046052114\\denemoprint8.ly"
C:/Program Files/Denemo/usr/share/lilypond/current/scm/lily.scm

John Beattie <jabeattie>
Tue 14 Aug 2012 03:05:19 PM UTC, comment #7: 

Tried with rc5.
When the Output device is set to MME -input (which was default) this still crashes.
When Output device set to the correct MME - output, there was no problem.

John Beattie <jabeattie>
Fri 27 Jul 2012 02:47:16 PM UTC, comment #6: 

I'm fairly sure that the soundmapper input was the one that stopped the crash happening. However I can't do any tests on at the moment as I want to leave denemo running for a few more hour without me doing anything to it as part of the  check for the other crash that might be caused by highlighting cursor.

John Beattie <jabeattie>
Fri 27 Jul 2012 01:53:36 PM UTC, comment #5: 

hmm, yes, that machine also has MM soundmapper Input as the first in the list, and that was what was showing. But it played ok. When I actually selected Input from the drop down list it did not play, but when I selected default it played ok, even though when I returned to the preferences the Output was showing as Input again (ie not as defaul). Selecting actual outputs worked. Nothing crashed on exit though, with or without cursor highlight checked.
There appears to be a bug in that cursor highlighting preference is not respected on re-start...

Richard Shann <rshann>
Group administrator
Fri 27 Jul 2012 01:40:26 PM UTC, comment #4: 

Oh, right, either change Input to Output or turning of the flashing cursor. I'll try these settings on the machine I have access to.

Richard Shann <rshann>
Group administrator
Fri 27 Jul 2012 01:38:27 PM UTC, comment #3: 

I just remembered that you can turn off thumbnails via preferences, miscellaneous->Enable Thumbnails

I don't think I have followed the bit about "changes made to setup" meaning no it is no longer crashing...

Richard Shann <rshann>
Group administrator
Fri 27 Jul 2012 08:57:59 AM UTC, comment #2: 

Following changes made to setup  in bug 36968 "Another crash with 0.9.5 rc2 on Windows", this is no longer crashing though it does still try to do the thumbnail.

John Beattie <jabeattie>
Thu 26 Jul 2012 09:09:42 PM UTC, comment #1: 

This is due to denemo spawning on exit a denemo run which typesets a few bars of your score as a thumbnail. This is probably useless on Windows as the conventions are all different. It will be worth omitting this.

Richard Shann <rshann>
Group administrator
Thu 26 Jul 2012 08:56:27 PM UTC, original submission:  

This also is happening every time I try it - don't think I saw it with rc1.

Load denemo, which load up my last music (which typesets correctly).
Press the close window X in top right hand corner to close window.

An * appears at the end of the Window tile (source file name) indicating that changes have been made (no changes were made).
Then Lilypond runs to typeset music (no typeset commands were issued.
Crash (sometimes the Window message saying denemo "has stopped working" appears before the lilypond progress window but you do see both)

Stdout says
stopping playback
Created temp dir C:\Users\jab\AppData\Local\Temp\Denemo-1325930763
rootdir=C:\Program Files\Denemo\usr
bindir=C:\Program Files\Denemo\usr\bin
newstaff: Num staffs 0
Setting measure to 1 which is last in Staff
Removed 0
that's it, i quit!
destroying dummy audio backend
destroying dummy MIDI backend

Stderr has lots of info relating to lilypond run so I'll just give highlights.
Firstly I'll remind you that the music loaded typesets correctly!
In Stderr the typeset fails because lilypond is trying to interpret \ in file name in default tagline as directives (see an earlier bug). This actually has nothing to do with tagline - it indicates a problem in lilypond init files (so this typeset must be using different combination of init files from me!).
Lilypond seems to recover from this and carries on interpreting music...
Start creating output files:
Converting to PNG...[C:/Users/jab/AppData/Local/Temp/Denemo-227195388/denemothumb.eps]
Layout output to `denemothumb-1.eps'...
[C:/Windows/fonts/CenturySchL-Bold.otf]
[C:/Windows/fonts/CenturySchL-Roma.otf]
[C:/Program Files/Denemo/usr/share/lilypond/current/fonts/otf/emmentaler-18.otf]
Writing denemothumb-systems.texi...
Writing denemothumb-systems.tex...
Writing denemothumb-systems.count...]
error: failed files: "C:\\Users\\jab\\AppData\\Local\\Temp\\Denemo-227195388\\denemoprint.ly"
C:/Program Files/Denemo/usr/share/lilypond/current/scm/lily.scmInvoking `gs  -dEPSCrop -dGraphicsAlphaBits#4 -dTextAlphaBits#4 -dNOPAUSE -sDEVICE#png16m -sOutputFile#"./denemothumb.png" -r300 "denemothumb.eps" -c quit'...

(denemo.exe:81480): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file 'C:\Program Files\Denemo\usr\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache': No such file or directory

(denemo.exe:81480): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file 'C:\Program Files\Denemo\usr\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache': No such file or directory

(denemo.exe:81480): GdkPixbuf-CRITICAL **: gdk_pixbuf_loader_write: assertion `error == NULL || *error == NULL' failed

(denemo.exe:81480): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file 'C:\Program Files\Denemo\usr\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache': No such file or directory



John Beattie <jabeattie>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rshann (Posted a comment)
  • -email is unavailable- added by jabeattie (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-08-18 rshann Open/ClosedOpen Closed
    2012-08-18 rshann StatusIn Progress Fixed
    2012-08-17 rshann StatusNeed Info In Progress
    2012-07-27 rshann StatusIn Progress Need Info
    2012-07-26 rshann StatusNone In Progress
        Assigned toNone rshann

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code