Build crashes without logs to it or why it happened

We're working on a simulation game. When the number of entities are high enough, the game just crashes without messages or prompts or whatsoever. I looked at the logs and there's nothing there. The memory usage hovers around 2100MB to 2300MB before it crashed. This is for 64bit systems so it should be able to handle that much memory. (Or am I wrong with this?) I tried replicating in editor but nothing happens. There are no errors or weird behaviour.

We're also using 2 threads for A* searching. It's just an infinite loop that continuously checks for A* requests queue. Could this have an effect? Do I have to stop the threads at some point and restart them.

Where do I begin to try to fix this?

 

So this is in a build not in editor, right? You're definitely building a 64-bit player? It sounds like a 32-bit player and you're running out of memory.

Sam

 

Yes, it's happens when running the windows build. I was hoping that I wrongly picked x86. But it's not. It's definitely 64bit. The build settings are set to Windows and x86_64.

 

That is super weird. I would attach Visual Studio and see if I could get it to crash in the IDE and see if the callstacks make any sense. Even if it crashes deep in Windows somewhere, it might still give some hints. You'd probably have to get VS to auto-download symbols from Microsoft's symbol server.

What does the end of your log look like? Does it look like it's been cut off or does it look like your game has shut down normally?

Sam

 

It looks like it's been cut off. Usually, in other crashes, errors are being logged. This time, there isn't any.

 

Im getting the exact same thing.

 

Sometimes happens to me too.

 

Anyone knows what happened here? It seems we're getting the same problem...

##utp:"type":"MemoryLeaks","version":2,"phase":"Immediate","time":1567583844753,"processId":18120,"allocatedMemory":17930,"memoryLabels":[{"Default":1048},{"NewDelete":336},{"Thread":8},{"Manager":320},{"VertexData":528},{"Shader":1176},{"GfxDevice":7920},{"Physics":32},{"Serialization":40},{"Terrain":88},{"String":962},{"DynamicArray":640},{"PoolAlloc":-88},{"Sprites":4096},{"VR":536},{"SceneManager":280},{"Secure":8}]}

this is the only message that is logged in before our Windows x64 build crashes. No other message, exception, crash report... Even with the managed debugger attached we couldn't get anything.
I can't seem to find anything regarding that message anywhere either

 

Thank you for taking the time to post this quick reply. Yes I did attach the debugger, to no avail.

BUT long story short (it was pretty funny so would actually be worth telling,but would probably take too long), the problem was on our side (and as one may be able to foresee with my previous parenthesis, quite a stupid/funny one, nothing to do with tech).

I'm still glad you told me about the ##utp log, as I had never seen it before (previous project was still under 5.x) and seeing "MemoryLeaks" in the 1st 3 words doesn't make for a good omen!

 

I just had an issue like this. It turns out there was something wrong with my terrain object.

To find the issue I saved a copy of the scene, deleted half the objects, and built it. It did that over and over until I got to the object causing problems.

 

-
Can you go in-depth about the problem you had? I'm currently experiencing the same thing or something extremely similar.

 

It just happened that our app was being quit properly (hence no logs) by an actual Quit UI button, the caveat being that said button was invisible and supposedly scaled to 0,0,0 ; but, at least in the Unity version we were using -- 2018.3/4 -- even though the UIRect was indeed scaled to 0 it appeared that it wasn't possible for it to truly be of size 0 => this invisible button still had a hitbox of 2x2 or 4x4 px, I don't remember).

 

I'm having this problem too! At first I did get a bug in the debug mode (That when I was searching if the renderers sharedmaterial maintexture was null, my shadergraph shader didn't use the name _MainTex so it couldn't check).

After fixing the bug, the game crashes with no logs of anything.

I know the problem comes from creating linerenderer in a script. But I have no idea what the problem is. Has anyone else figured something out?