Crashes & hangs in recent builds (since 4352)


#1

We recently merged a build that did changed the threading behavior in Interface in order to improve the UI responsiveness even when the rendering rate is low. The bad news is we’re seeing a lot of side effects from this merge in the forms of crashes and hangs. The good news is we’re working hard on fixing them.

For hangs, build 4367 introduced code that will intentionally trigger a crash if the application hangs for more than 10 seconds. This should enable us to get information through the error reports that will let us find and stop these hangs in the first place. So if interface stops responding, please don’t kill it manually until at least 15-20 seconds have gone by without it killing itself and bringing up a crash window.

And for those crash windows, please do send them. Right now they’re kind of critical to creating a stable build. Thanks.


#2

Awesome!
<>==(|==============>


#3

Yep, tried the recent build to check the changes to the Material stuff, but I kept CTDing on startup. So waiting for a fix for that. Sent a couple of crash reports.


#4

Interface crashes on every attempt to start it. This includes having reset my settings. So, ouch, awaiting fix.

[edit]
Happens with 4370and two previous releases.


#5

4367 Cleared the crash case that was 100% for 4365 and 4366 here. Maybe it’s my lucky day. Or !lucky since I’m trying to find crashes, !avoid them. Sighs.


#6

I rather like this fix: Plant that blooms flowers when it is watered by a water can


#7

4370 crashes on every start-up for me. Windows. After uninstalling, deleting cache and ini files, and installing.


#8

This is not a deadlock timeout crash since it happens immediately.

[03/09 13:02:39] [DEBUG] Attempting plugins “openvr.dll”
[03/09 13:02:39] [DEBUG] Plugins “openvr.dll” success
[03/09 13:02:40] [DEBUG] Waiting for inital public socket from STUN. Will not send domain-server check in.
crash


#9

Mine appears to be a deadlock crash. My program log continues on from Balpien’s…

… lots more lines then, finally …
[03/10 09:57:23] [DEBUG] Sending intial stun request to stun.highfidelity.io
[03/10 09:57:24] [DEBUG] New public socket received from STUN server is 118.93.233.178:49706


#10

Clean local build crashes on deadlookDetectionCrash(). Every time.


#11

Yes, this is why it looks to me like the deadlock detection code is not initializing whatever it uses to detect a deadlock, probably in thread creation.


#12

Commenting out that line … //deadlockDetectionCrash(); … Interface just hangs with white screen. So for me, at least, it does seem to be a successfully detected deadlock crash.


#13

Well as long as its intentionally broken we can all rejoice :smiley:


#14

Earlier today there was an issue with some incompatible files - if you’re still having 100% crash on start try uninstalling interface and reinstalling. That’s un-related to the deadlock issue as it never gets a chance to deadlock, it just crashes straight away.


#15

A lot of the crashes seem to be occurring in menu initialization, specifically when we create the duplicate of the app menu for use in the scene. I’ve just updated https://github.com/highfidelity/hifi/pull/7259 with some changes that should prevent crashing within the menu. It’s likely that the application will still be broken in some fashion when it comes up, but we should at least be able to glean more information from logs and the behavior than we can from crashing.


#16

This should be fixed with 4374 that just went out, without needing to uninstall and reinstall.


#17

4375 works OK. Thanks.