Absolutely. Hopefully DD can come up with something new, or maybe he'll discover he was wrong about the version too. He said he's on 1464, but it just doesn't make any sense and I've had no luck reproducing the issue.
| |
Managed to reproduce. Unfortunately... I didn't have my task manager up to view the resources during it. If you think that's still relevant I can try and capture it again.
Also unfortunately (or, rather fortunately for what I was working on) it didn't corrupt the icon. Here's a clip of it. Again, skip to the last minute or so. https://streamable.com/c7z0t My inputs for sure were just... - Copy recently modified states - Paste to other direction(s) within state editor - Ctrl+S I save after every state addition. It rolled back this save and the save did not complete. It's created two crash logs, I'm uploading them to pastebin to avoid putting them in quote blocks. Here's the first: https://pastebin.com/gXQ729pd And the second: https://pastebin.com/qt3SVi90 Is there any other information I can give you? | |
Got a corruption this time, though I'm not sure more clips will help too much, this one's interesting.
https://streamable.com/g96sv This time the windows error event name is "BEX." Though I'm unsure what that means, maybe you'll make more sense of it. https://pastebin.com/SCc2VyUA | |
The crash you got Saturday is very interesting because it's happening in rgbaToPalette(), a routine that's called during the write of a .png file (and therefore also a .dmi).
The only obvious reason I can see this routine failing is if it did in fact run out of memory, since it was written without a sanity check. I'm adding a sanity check, which should help somewhat, but the bigger picture appears to be from Dream Maker being unable to allocate more memory. Therefore it seems like it is in fact likely hovering close to its limit at the time of the crash, but of course I need you to verify that. The second crash isn't the same, but because it's happening in a DLL we don't control it's hard to tell what's happening. A minidump file might be helpful for that particular crash, if only to show more info about where the crash originated, although if the problem is being out of memory it'll still be hard to diagnose. What's really strange to me is that it should be hard for Dream Maker to run out of memory here. Yes it's carrying undo/redo info for your icons, but it shouldn't really be any bigger than the icon data itself. I'd like to see some info on what your memory consumption looks like over time as you do icon editing. I would say based on my data so far, now that you've updated to 1464 I suspect you're not getting these crashes after just opening Dream Maker. Also just to be clear, I need to know Dream Maker's memory consumption alone, not total system memory. DM should top out at close to 2G regardless of total system memory. If it's getting near there, that would suggest to me either a leak or maybe having too many icons open. In your stream I see you only have two tabs with icons open; however I also see that the icons are 200x200 rather than the 120x120 that DragonDesend mentioned, which is a little less than 3x bigger in terms of pixel size and memory footprint. It would be helpful also if you could send me some of these completed character icons with all the states, just so I can get a grip on the footprint of each. | |
If it means anything, it does feel like every save I do as I modify these .dmi files, the save takes just a little bit longer, up until the point of the crash. The corruption is what makes this really weird, because it seems like there's no rhyme or reason to it. Additionally, sometimes it'll leave behind some .dmi.tmp files, as though it's partially saving along the way. These files have a file size of 0 bytes, so nothing's being written to them. Very strange, to me at least.
I'll start having some resource monitoring open for Dream Maker when I make some newer icons today, I've got a rather annoying one I plan to make, so it'll be the perfect opportunity. About that minidump file... Where would I find that at? I tried checking my %systemroot% directory, but there're no traces of one. I might need you to walk me through setting that up to catch the next crash. Also yes, the icon I was working with sadly needed to be larger due to some of the states having some objects project out of the character within it. I was too lazy to cut them and make them their own icon and project them out that way, so I just recentered based on their width. Here's a sendspace link with some of the character icons: (Deleted, already dl'd) Most of those are pretty recently created, and almost all have been edited on the latest build to some extent. They're not original content so I have no problems uploading them here whatsoever. | |
I've never had occasion to make minidump files myself so I'm not sure where they get generated, but that's something you could look up.
Loading the icons you sent into a test project, I saw Dream Maker's memory climbed over half a GB when all of them were in tabs, so if your icons have been accumulating undo states it's quite likely that the memory is getting choked out. Maybe I can add some more sanity checks in there, perhaps something to look at DM's current usage and see if discarding undo states would be wise. It'd probably also be a good idea for me to add some sort of support for compressing the icon data. The internal PixBits structure doesn't allow for this, but there's no reason the data can't be set aside somehow and recreated as needed, especially in the main icon editor vs. the pixmap editor (where it'd be more complicated). | |
I took a look into making minidumps. My directory's set correctly, and I've disabled the deletion of the previous minidumps when a new one is created, so tonight I'll hopefully be able to have some.
Perhaps, if your theory about the undo states is true, we're taking it to the max by using our arrow keys of all things to recenter them (does that create a bunch of undo states?) Might be a reason why we're experiencing this issue rather than others. Then again, most people I know who gfx for money on BYOND do so with photoshop or some other pixel editor like Aseprite. In any case, I'll reply to this again if/when I catch something tonight. I'll do my best to catch the memory stats as well. Thanks a bunch for being so active with this. | |
Using the arrow keys in the pixmap editor will not create a ton of undo states, because shifts are considered "stackable" actions. Left/right shifts get combined into a single action, and so do up/down shifts. Also, any undo states get deleted when the pixmap editor is closed.
| |
I've made a couple of really good discoveries.
It turns out memory most definitely is an issue. In these two clips, I first find out that shifting them with the arrow keys the way I usually do, especially on states that have more than 10+ frames, takes up quite a bit of memory. This memory usage drops back down to a semi-reasonable spot when I back out of the state editor. Here's the first clip of me discovering this: https://streamable.com/w7j8x (At time of this post, the upload isn't complete. If you're reading this right after I post this, give it a few minutes.) Next, I tried to instigate a memory-focused crash. I suppose I didn't have to try, because you had already said that it would crash at 2G, but I felt I wanted to confirm it. Here's that clip: https://streamable.com/dlfm9 However, this isn't exactly the same issue that's corrupting our files, or causing us to be unable to read them, but it most definitely is an issue with how Dream Maker handles memory for these states. I'm going to continue recording with the task manager active to catch the initial issue red-handed. Oh, and on the topic of those minidump files you mentioned... It turns out that they aren't even being created for this issue. I've searched all of my partitions and there're no minidump files. I've made sure they were active and being sent to a valid directory... They just aren't being created. Edit: Had to reupload clips | |
Aha, I see in your stream that a big part of the problem may be that you're shifting left/right then up/down and vice-versa a lot, so instead of doing the X shifting first, then the Y, you might have a lot of cases where you go back and forth. I think it would be wise for me to make all shifts stackable, instead of just stacking only X and Y separately.
The memory being freed after you exit the pixmap editor makes solid sense because it clears out undo states when it exits. For clearing undo states from the main icon editor, a good workaround if you want to keep memory manageable is to close the icon when you're done with it, avoid having multiple icons of this size open at a time, and after a few major edits to it you might want to close the tab and reopen the file. | |
Gotcha. I'll start doing that to avoid this issue.
I noticed that drop in memory usage, commented on it, then realized in my head that you had mentioned it dumps the undo states upon backing out to the main icon editor. I'll start abusing that if I get all sporadic with my relocation until your newest release. Still no luck on reproducing the corruption. I'll continue to play around. Hopefully the memory issue is what builds up to that. For now, I'm just happy we've made some progress. | |
I'm quite certain the corruption is caused by the crash happening during the save process. Having it corrupt intermittently is pretty expected for a problem that occurs on save.
| |
Just want to put an update about the issue of dream maker closing on compile -
the issue is still occurring, a lot more frequently now actually. every other compile the source will just close. | |
I still need you to collect data on memory usage and crash details whenever this happens. Just telling me it's happening doesn't give me the info I need to investigate and correct the problem.
I know in your specific case, memory usage was one of the big issues, so you should be looking at Task Manager to keep an eye on DM's memory use. If it's starting to creep up, you should close tabs you're not using, and if that's not enough then reopen and compile in a new session. I'd also like info on what was causing the creep-up, how many tabs are open, etc. | |
I open the source, and compile.
There's no other steps or things open, 1 - 2 tabs most of the time. And it'll either close or compile, I can send you the source in question to see if you can replicate it (The other person who works on the source with me says he gets it every 4 or so compiles) | |
I tried for a little to reproduce the problem, but I was unable to do so.
DragonDesend has unfortunately gone on a bit of a hiatus, but I suspect he'll be back soon enough, hopefully with more information on this.
As far as I go, I'm back at home and not working with BYOND much for this week, what with working over my break from college. When I return back to my dorm I'll be back to it.
Is it alright if we leave this report open, and if I DO manage to crash it, I'll reply with all the information you requested earlier?