search

rubenwe / StlVault

3D object viewer and organizer
http://stlvault.com
MIT License
167 stars 26 forks source link

Crashing while opening. #55

Closed mcenal closed 4 years ago

mcenal commented 4 years ago

STLVault-20-06-20-22-11-29.zip

mcenal commented 4 years ago

I've added in a ton of stl files into my collection of various sources. I can't get the application to stay open for more than a few seconds before it crashes.

rubenwe commented 4 years ago

Hi @mcenal - I'll take a look and will get back to you. Thanks for reporting!

mcenal commented 4 years ago

So strange things happening, I think it is related to the ram usage/GPU usage/CPU thread usage. I'm not sure why, but I rebooted my computer and started loading a folder at a time and then exiting after each successful import and it is no longer crashing. So maybe it has to do with resource use. I would suggest that you include a bit more detail in the crash/report and or try to catch the crash error better without closing the application. Perhaps have a log of the file that crashed and then skip and move on or end the import.

rubenwe commented 4 years ago

First of all: Thanks for following up in the discord and for trying to help me reproduce the problem. It's indeed quite a strange crash and I might need to add some additional logging and profiling so we can track this down.

try to catch the crash error better without closing the application

I'd love to do that - but some errors are unrecoverable. In this case the log showed an access violation. That's usually a thing that happens when you write or read memory that doesn't belong to a process (anymore). When this happens, the process memory is in an unexpected state. The way STLVault is built I don't think I can do a lot to handle these - the Unity runtime will force a shutdown when one of these occurs. The reason for that is, that it is usually the "right thing" for a process to do in this situation. The data that was read or written is often incorrect or lost - so the "sane" thing to do is to stop everything and halt the process.

So what this means is that the only way to prevent those crashes is to not have code that does this. I'm not certain in this case, where exactly things go wrong (which is why we need improved tracing or better dumps).

This could totally be my doing: I have some "unsafe" code in the STL-Parser. There is a chance that it reads out of bounds. In that case it should crash regardless of how you import the files, because those errors would be based on the content of the imported files. Now that not being the case, this might well be an error in the Unity runtime.

And those might well be harder to track down. I have some work planned to move the parsing and most of the library stuff out of process. This means that it should be a lot easier to track down issues like this and the overall memory pressure and busy times of the vault will become a lot smaller.

If you do come across a reproducable failure while importing a fixed set of models again, let's take a look. Because I still hope the error is on my side. That would be a lot easier to fix. Feel free to comment on this issue again or open a new one in that case.