Godot hangs after returning from hibernate.

[Fachtna]

Operating system or device, Godot version, GPU Model and driver (if graphics related): Windows 7, Windows 10 Godot 2.1.4 stable win64

Issue description:

Upon returning from hibernate godot is unresponsive and never recovers. This occurs in all areas, e.g. Project Manager and when in a new or existing project

The console window that opens appears responsive however no text is written to it whilst the main godot window is hanging whilst viewing the Project Manager list

Steps to reproduce:

1. Open Godot
2. Hibernate (shutdown /h)
3. Resume from hibernate

Event Log

---

Windows Error Reporting

Fault bucket , type 0 Event Name: AppHangB1 Response: Not available Cab Id: 0

Problem signature: P1: Godot_v2.1.4-stable_win64.exe P2: 2.1.4.0 P3: 59a2fb1f P4: cb63 P5: 134217728

Analysis symbol: Rechecking for solution: 0 Report Id: 5ad078be-a967-47bf-9bfe-c45a4027691b Report Status: 97 Hashed bucket:

---

Application Hang

The program Godot_v2.1.4-stable_win64.exe version 2.1.4.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel. Process ID: 1600 Start Time: 01d33c185cfb353e Termination Time: 8 Application Path: C:\Projects\Godot\Godot_v2.1.4-stable_win64.exe Report Id: 5ad078be-a967-47bf-9bfe-c45a4027691b Faulting package full name: Faulting package-relative application ID:

• System

  • Provider

  [ Name] Application Hang

  • EventID 1002

  [ Qualifiers] 0

  Level 2

  Task 101

  Keywords 0x80000000000000

  • TimeCreated

  [ SystemTime] 2017-10-03T07:23:57.620392700Z

  EventRecordID 15795

  Channel Application

  Computer DESKTOP-VIC2D6S

  Security

• EventData

  Godot_v2.1.4-stable_win64.exe 2.1.4.0 1600 01d33c185cfb353e 8 C:\Projects\Godot\Godot_v2.1.4-stable_win64.exe 5ad078be-a967-47bf-9bfe-c45a4027691b

  55006E006B006E006F0077006E0000000000

---

Binary data:

In Words

0000: 006E0055 006E006B 0077006F 0000006E 0010: 0000

In Bytes

0000: 55 00 6E 00 6B 00 6E 00 U.n.k.n. 0008: 6F 00 77 00 6E 00 00 00 o.w.n... 0010: 00 00 ..

[marcelofg55]

Just tested this, didn't happen for me with latest 2.1

[mhilbrunner]

Doesn't happen for me with latest Godot 3.0.

[reduz]

I dont think godot even knows what hibernating is, so most probably a driver bug

On Tue, Oct 3, 2017 at 12:21 PM, mhilbrunner notifications@github.com wrote:

Doesn't happen for me with latest Godot 3.0.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/11799#issuecomment-333876932, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z26Ie-GMq_HUkVfRMtTEBMjbDjYxbks5solEOgaJpZM4Prs23 .

[Fachtna]

It's a bit hard to imagine a driver bug across 3 different machines i'll try test it on a few more and see if i can find anything common across them.

Drivers are all up to date on all machines, no other program has an issue with hibernation even various games.

Godot is the only one failing to recover after a hibernate.

I notice i do have a small window to continue using godot before it crashes sometimes, this doesn't seem to be the first issue mentioned relating to hibernate problems in godot, e.g.

https://godotengine.org/qa/6039/found-godot-issues-bugs

I'll also check godot 3 later today as well to see if it has the same issue.

[reduz]

Ah, it maaay be related to the clock skip, that would be intersting to test.

On Tue, Oct 3, 2017 at 7:28 PM, Fachtna notifications@github.com wrote:

It's a bit hard to imagine a driver bug across 3 different machines i'll try test it on a few more and see if i can find anything common across them.

Drivers are all up to date on all machines, no other program has an issue with hibernation even various games.

Godot is the only one failing to recover after a hibernate.

I notice i do have a small window to continue using godot before it crashes sometimes, this doesn't seem to be the first issue mentioned relating to hibernate problems in godot, e.g.

https://godotengine.org/qa/6039/found-godot-issues-bugs

I'll also check godot 3 later today as well to see if it has the same issue.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/11799#issuecomment-333997440, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z2-Ci9UN_tWQ-H1etMJIDcZSc1SMhks5sorTzgaJpZM4Prs23 .

[Fachtna]

Also if it helps godot is stuck using 100% of one core after coming back from hibernate.

I've tried to debug it with visual studio and a message appeared in the console output (godot still frozen)

WARNING: AudioDriverRtAudio::callback: RtAudio output underflow! At: drivers\rtaudio\audio_driver_rtaudio.cpp:57

however the underflow may be unrelated as I've had that occur in the past when it was working fine.

Will try and get more info.

[reduz]

it sounds like a timer skip issue, can you a state of the threads?

On Tue, Oct 3, 2017 at 7:37 PM, Fachtna notifications@github.com wrote:

Also if it helps godot is stuck using 100% of one core after coming back from hibernate.

I've tried to debug it with visual studio and a message appeared in the console output (godot still frozen)

WARNING: AudioDriverRtAudio::callback: RtAudio output underflow! At: drivers\rtaudio\audio_driver_rtaudio.cpp:57

Will try and get more info.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/11799#issuecomment-333999162, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z2-CorzJJ9YT2UzcyhqAbjqWetQruks5sorcngaJpZM4Prs23 .

[Fachtna]

Wow I think the issue is related to team viewer 12 I saw this in the stack trace which was weird so i closed teamviewer and disabled the team viewer service reloaded godot and tried to reproduce using shutdown /h it seems to be working fine now, the other two computers also have teamviewer installed so i'll need to test them without it.

Maybe it is driver related and the two applications are competing for some resource (maybe the audio?)

[BastiaanOlij]

I love teamviewer, we use it extensively, but yes, the later versions do seem to be very intrusive and lead to some weird issues. I've had inexplicable crashes in several applications when teamviewer is running.

[marcelofg55]

I stopped using teamviewer myself after they started having security issues with accounts.

[BastiaanOlij]

@marcelofg55 thats a two edged sword. Not wanted to stray away from the topic of crashing, I will say this.

It often takes a security breach for companies to get their ass into gear and make the right changes. It's amazing some of our clients jumped ship and started using other screen sharing technologies, often ones that were even less secure then team viewer, but they hadn't been breached yet so they feel safer. In the mean while, Team viewer has done a relatively good job in learning from the experience and upping their security measures.

Heck, one of the things that really drops my jaws are those who abandoned team viewer because their new added security measures make the product harder to use, so they go to other products that are easier to use precisely for the reasons why those product are even less secure.

[vnen]

What is the status on this? Is there something we need to fix in Godot?

[starry-abyss]

I don't use team viewer, but I use suspend to RAM on Windows 7 64 bit. As of 91ed678 the editor usually recovers normally, but sometimes it crashes. This time I saved a minidump, but not sure if it's any useful:

[vnen]

@starry-abyss this looks like the crash happened in the graphics driver.

[mhilbrunner]

I observed some other weirdness while having Teamviewer installed in the past. I would cautiously close this and reopen if somebody has more information and it doesn't seem Teamviewer related. I.e. somebody has crash logs or something.

[vnen]

TBH I'd say this is more a fault of the operating system than anything else, since it fails to properly restore the state of the applications (especially the VRAM). Many crashes and BSODs stopped happening for me after I disabled the fast startup.

I don't think there's anything we can do to fix this.

[starry-abyss]

Just a thought - if the video drivers work like this, maybe Godot could re-upload all textures on wake up? Also I remembered - I also had issues with crashing and hanging of other programs, including ones that don't do hardware-accelerated rendering, like FlashDevelop or git-gui (almost certainly will hang or crash), but for others like Firefox, foobar2000, Notepad++ I can be sure that they won't crash after waking. Godot is kind of in the middle for me, it may or may not recover

[mhilbrunner]

More affected people, it seems: https://github.com/godotengine/godot/issues/11799

[starry-abyss]

@mhilbrunner You probably wanted to point to some other similar issue, not this one?

[mhilbrunner]

:P Seems like it, though now I lost it. Don't know.

[Calinou]

Closing, as this is likely a system/driver-specific issue that can't be resolved on our end. Still, please comment if you can still reproduce this bug in Godot 3.2.1 or 3.2.2beta4.