ashwin.sudhir Posted May 11, 2012 Share Posted May 11, 2012 There's a crash happening in Unigine which we are unable to troubleshoot, especially since we do not have the Retail symbols. Per manguste's advice here https://developer.unigine.com/forum/topic/1083-how-to-report-unigine-crashes/page__fromsearch__1 we have attached a screenshot of the callstack and the logfile. CallstackAndLog.zip Link to comment
unclebob Posted May 12, 2012 Share Posted May 12, 2012 Hi, First, as you can see in log file there are huge missing content such as nodes and textures, especially nodes. This will get you null references and etc. which can be major reason of random crash. Try to cleanup your content and then look for crashes. If it still happens then you can give callstack to us. Second, the callstack you given provides minimal information because there is no debug symbols included during debugging process. Could you provide callstack with debug symbols enabled? Link to comment
ashwin.sudhir Posted May 14, 2012 Author Share Posted May 14, 2012 Hi unclebob, Even if there are multiple missing assets, I'd expect Unigine to be robust enough not to crash. In fact, Unigine does not crash most of the time and as I said in the thread title, this is very random. I'd say the easiest way to troubleshoot this kind of ting would be to share Retail symbols with your clients. We had requested this earlier by mail, but got no response. Link to comment
unclebob Posted May 15, 2012 Share Posted May 15, 2012 Hi Ashwin, As far as I know, you have binary SDK license. This type of license contains debug symbols so you can see callstack properly. Please check your lib folder for Unigine_x86d.pdb and Unigine_x64d.pdb files. Maybe I get you wrong. What do you mean by 'Retail symbols'? Link to comment
ashwin.sudhir Posted May 16, 2012 Author Share Posted May 16, 2012 @unclebob This crash does not happen when we link to Unigine_x86d lib or dll. This seems to happen only when we link to the Unigine_x86 (retail) libraries. we cannot use the Debug pdb's with the retail libraries, can we? This is the reason why we are unable to give you the callstack with proper symbols. I am not an expert in this, but i doubt the pdb's you mentioned can be used with cashes that happen inside Unigine_x86 (not _x86d). This is why we requested symbols for Unigine_x86 libraries. This is a bit like the service that Microsoft's symbol server offers where one can get pdb's for a lot of released windows components, Visual Studio etc. Link to comment
unclebob Posted May 21, 2012 Share Posted May 21, 2012 Hello Ashwin, Sorry for late reply. I can build release symbols and binaries for you. Could you specify your platform and engine revision? Thanks! Link to comment
unclebob Posted May 22, 2012 Share Posted May 22, 2012 Okay, I've built x86/x64 windows binaries for you. I assume your engine revision is r8221 (this is what I found in log file). Please try them. binaries-r8221.zip Link to comment
ashwin.sudhir Posted May 23, 2012 Author Share Posted May 23, 2012 Hi @unclebob I tried downloading the zip file 5-6 times (with and without using download managers) but everytime I tried to open the file, it says "archive corrupt". Link to comment
manguste Posted May 23, 2012 Share Posted May 23, 2012 Hmm, the archive is downloaded without any problems. Anyway, do you have a file server so we can share it with you? Link to comment
ashwin.sudhir Posted June 5, 2012 Author Share Posted June 5, 2012 Using the Retail symbols I was able to get this callstack ParticlesUpdateCrash.zip Link to comment
ashwin.sudhir Posted June 5, 2012 Author Share Posted June 5, 2012 And another one, if it helps Link to comment
unclebob Posted June 8, 2012 Share Posted June 8, 2012 Hello Ashwin, Sorry for late reply. Looks like crash appeared when you select one of the units that newly created. Am I right? Could you provide that skinned meshes. If possible, provide to us your game build. It'll help us a lot to get to the problem. Also, try to set world_threaded to 0 in config file and try to reproduce this crash. Thanks! Link to comment
ashwin.sudhir Posted June 11, 2012 Author Share Posted June 11, 2012 Hi unclebob, thanks for your reply. We can't say exactly what caused the crash as lots of things happen on screen when crashes happen. My guess is that it's not a trivial case like selecting a new unit, because this crash is not very frequent, though we have regular playtests all through the day. If I'm not wrong Team Unigine already has access to our builds, if this is not the case do let me know and I'll follow up on getting you access. We will try your suggestion of "set world_threaded 0" hopefully performance won't be compromised.... Link to comment
ulf.schroeter Posted June 11, 2012 Share Posted June 11, 2012 We will try your suggestion of "set world_threaded 0" hopefully performance won't be compromised.... This will disable multi-threaded node update, so in case of greater numbers of update-intensive objects (e.g. ObjectParticles, WorldExpressions, ObjectMeshSkinned,.. ) this will increase your update time per frame Link to comment
ashwin.sudhir Posted June 29, 2012 Author Share Posted June 29, 2012 Hi, We tried disabling the world_threaded 0 approach, but it hasn't helped much, attached are all the crashes we've had over the past week from our users. Link to comment
ashwin.sudhir Posted July 13, 2012 Author Share Posted July 13, 2012 Any updates on these? Link to comment
manguste Posted July 20, 2012 Share Posted July 20, 2012 Judging by these call stacks, the most probable culprit of crashes is referring to a non-existing object. That would explain the randomness. The same advice is in effect: clear up your resources, load them properly and send us reproduction steps. Link to comment
Recommended Posts