New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exporting large files shoots up resource usage and causes a crash #1125
Comments
Thanks for the report, I have edited your message to fix some lines that were interpreted as markdown. I will take a closer look at this on Wednesday, but until then there are some questions that might be relevant:
|
It happens after a couple of minutes when I do my thing & that includes when I'm interacting with layers & drawing. For the exporting multiple layers part, it loads until it comes to a halt & does nothing, I haven't waited long enough to see if it usually crashes.
(I used the 'free' command on linux)
(I was in the middle of something, after exporting 13 layers onto the file with 4, & doing what I wanted, it crashed at 3:46 PM (Pacific Time) at long last out of all the other times during the day. I ran your command & this spat out:
(This is just the chart frozen in time, it's constantly changing at the time I'm typing this)
I got 'MyPaint-v2.0.1.AppImage' from (https://github.com/mypaint/mypaint/releases/tag/v2.0.1) from clicking on Latest stable release. on(https://github.com/mypaint/mypaint), I'm not sure if the alpha appimages=my appimages |
Update (if this is even related): I tried to reload the crashed auto-save of the file that crashed but Mypaint crashed after awhile of waiting. |
(I meant the file that crashed at 3:46 PM (Pacific Time)) |
Okay did you test it with the latest builds that @jplloyd mention? We say that cause that lets us know if this is issue is persistant upstream and helps us identify the commit we need to patch into the stable builds and release a minor point release. Both the alpha and stable images have the same access to your filesystem. Just the alpha is newer than the stable. |
Ok, thank you.
1.5GB does usually not go very far when working on projects with large number of layers (depending on the size of those layers), but that's no excuse for not handling low-memory situations better (if that is the root cause).
Sorry, I messed up by omitting a flag (and not testing what I wrote), the command should have been:
The continous alpha appimages are rebuilt when a change is pushed (with some exceptions) so they reflect the latest stage of (published) development. You may notice that the alpha appimages have |
I could replicate the freezes on a Debian Buster installation on virtualbox (still can't say for sure that the cause of your freezes is the same): I set the memory available to the virtual machine to 1.5GB, and created an .ora file with 32 layers at ~3k-ish resolution. I zoomed in and out of the image a bunch, to generate and cache mipmaps for different levels of zoom. Then I drew across a bunch of the layers, trying to cover a lot of tiles, to fill the undo stack. With this I could get up to about 1.1G RES memory used by the process. Starting firefox and opening a few tabs with normal but inefficient websites (reddit, newspapers, etc) easily pushed the total memory usage to the limit. When trying to save the .ora file under these conditions, either firefox would crash silently (3/4 times, in my tests) or mypaint would after getting stuck for a while. When firefox crashes first, mypaint proceeded without crashing. |
I tested the crash on (MyPaint-v2.1.0-alpha-336-g453f4e8-2020-12-31_09.15.AppImage). I exported 24 layers. It froze at around 12:23 PM Pacific Time after awhile. |
I was trying to load my crashed save having 25 layers on (MyPaint-v2.0.1.AppImage). It loaded, I saved, then done a lot more stuff until it stopped responding. The tab closed with this message in terminal appearing: As for the 'top -p $(pgrep -i -f 'python.*mypaint') part, I'm not sure about it, I typed the command but there's no notable changes: Also, for the command itself, I know I should know how code works in the future but I honestly have no idea what to do I optimised the command into this: 'top $(pgrep -i -f 'pythonmypaint')' & I got this: top - 18:36:53 up 2:33, 0 users, load average: 0.00, 0.02, 0.12 (I'm pretty sure I'm doing something wrong) What now? |
Ummm... I think this is not supposed to be crossed out, how did it get crossed out? |
Sorry, I tend to assume knowledge about commands and such - bad habit.
Running Since you removed the Note that the process will not appear in the list if it is not running - so run the command after you start mypaint, but before you do the freeze-inducing things. In the terminal window running
The lines got crossed out because of the tilde characters in your prompt string (gh markdown manual) - place terminal output between two sets of three backticks to avoid formatting issues:
In short, we are interested in the memory usage of mypaint and the memory available to the system when the freezes occur. The time of the crashes is not important. |
DRIFT-VIDEO-2071823-2140528-1610068201517-1.mp4(I actually recorded the crash! Nice!) |
Ok, so it's using 99% cpu and quickly allocating quite a bit of memory. What were you doing in the program at the time? |
I decided to try & export around 24 layers or just making & polishing animation frames. (assuming my memory is right) |
Description of the problem
I was doing my usual save to organize stuff when I suddenly had this problem today. Every session, MyPaint seemed to freeze after a couple of minutes. After while, the tab closes (assuming I didn't start another tab of MyPaint). I tried uninstalling & MyPaint-v2.0.1-alt.AppImage, Linux, & even trying on another version (installing MyPaint-v2.0.1.AppImage & running it). I can always start another session after it freezes but I want to save time here.
Basic system details
Steps to reproduce
Backtraces or error messages
(A)
Gdk-Message: 18:14:58.541: Lost connection to Wayland compositor.
The text was updated successfully, but these errors were encountered: