Duke4.net Forums: [Fixed] Computer freeze when I quit the game, or alt tab - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

[Fixed] Computer freeze when I quit the game, or alt tab

User is offline   dragon84 

#1

When i quit the game or alt+tab I get a black screen.

ALT+f4 and CTRL+Del does not work so i have to unplug my computer.

Ingame it works fine, very strange. I use latest W10, i5 6600k and gtx1070.
1

User is offline   dragon84 

#2

Anyone else have this issue? I can't be the only one.. because this is a rather game - or would i say computer- breaking bug.

All recent builds from this year or so (that i have tested) have this issue.. Then i tested a very old build from 2015 and no problem.

If i use a non-SDL build called "eduke32-nonSDL-r8097" that i got here: https://forums.duke4...e/page__st__210, then there is no problem too. So i guess SDL is culprit?
0

User is offline   Forge 

  • Speaker of the Outhouse

#3

I'm going to help you, help yourself.

First - there's this sticky thread at the top of the page where you made this thread.

***Please Read This Before Posting Problems Or Bugs.***
https://forums.duke4...oblems-or-bugs/

so you should probably read that and all the stuff under the spoiler box
then it links to this page:

Troubleshooting EDuke32 article on EDukeWiki
http://wiki.eduke32....hooting_EDuke32

you should probably read most of that
also on that page you'll find:

Crashes
If you encounter an actual program crash, try running the debug executables (eduke32.debug.exe or mapster32.debug.exe) included in the EDuke32 builds available from synthesis. If you encounter the crash again, look for a file named eduke32.crash.log or mapster32.crash.log and include it when following the directions in the Basic Assistance section.

If you cannot find this file, please proceed to the Debugging section.


You should probably find that page and get the link to download the debug program and the link to the debugging section
0

User is offline   dragon84 

#4

Ok here are the details:

1)

eduke32.log

https://pastebin.com/n7PcAfDa

eduke32.crash.log

https://pastebin.com/jeWqfWXX

Error printscreen with debug version: https://i.imgur.com/4g5zRaK.png

2) Your system specifications. (OS, GPU, CPU, etc)

Windows 10 1903 build 18362.418
Nvidia gtx 1070 driver 436.48
Intel Core i5 6600k
16gb RAM ddr4 Corsair

3) What version of EDuke32 you are running.

Version 8248 x64 bits

4) What you were doing at the time.

Quit the game with Esc key and Y key.

6) Last working version and the first broken version

Didn't test every version, but Version 7067 is working.

This post has been edited by dragon84: 23 October 2019 - 06:30 PM

0

#5

I have encountered something very similar to what you are describing, although I do not get an error message on exit, nor do I have useful log outputs.

Alt-tabbing right after launching the game causes no issues, but on prolonged play (let's say 10+ minutes) the time it takes to tab out of the game increases significantly.
First it will only take a few seconds, but eventually it can take up to several minutes to do so. Using the CTRL+ALT+DELETE combination also does not work, and in my case leads to explorer.exe crashing.

Furthermore, and even more curiously, having the game run for extensive periods (let's say a couple of hours) will eventually lead to random framedrops occurring, which will appear to the player like random lag.
At this point, if the player tries to exit or tab out, it will almost certainly take several minutes for it to do so. In one instance I did experience the same hang-up that dragon84 described, black screen and everything.

From what I can tell, this issue started appearing with r8139:

Quote

Partial timer cleanup

After this revision, the only place timerUpdate() is called is from within handleevents(). S_Cleanup(), MUSIC_Update(), and G_HandleSpecialKeys() are now called from a timer callback set with timerSetCallback(). This more or less deprecates the usage of faketimerhandler() in EDuke32 and Mapster32, but other games still rely on the functionality.

With revision prior to this one, I can cleanly tab out with no delay.

This post has been edited by Doom64hunter: 23 December 2019 - 10:44 AM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #6

If you could run the binary in GDB, Ctrl+C or F12 during such a stall to send SIGINT and trap into the debugger, and get a backtrace of what's taking so long, it may help.
0

#7

View PostHendricks266, on 23 December 2019 - 11:02 AM, said:

If you could run the binary in GDB, Ctrl+C or F12 during such a stall to send SIGINT and trap into the debugger, and get a backtrace of what's taking so long, it may help.

Tried doing this on Windows and the stacktrace doesn't really give me any useful information unfortunately. I think it might actually be the operating system as a whole stalling, rather than just eduke32.
Might check on Debian later and see if I get the same slowdown there.

This post appears to be discussing a similar issue: https://forums.duke4...post__p__333541

Quote

When I manually change the focus (alt-tab or other means), the program freezes for some seconds, or even a dozen of seconds for changing the keyboard layout.

However, using the revision that removed the keyboard layout switching, I'm still nonetheless getting the same slow window change, so we can definitely rule that out as the cause.
Furthermore, I was able to determine that the problem only occurs on Polymost. Both Classic mode and Polymer are unaffected.

Edit: In case it helps, here are my specs:

Windows 10 Pro, Version 10.0.18363 Build 18363
Processor:  Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz, 3301 Mhz, 6 Core(s), 12 Logical Processor(s)
GPU: NVIDIA Geforce GTX 970
16 GB RAM
1920x1080 Monitor;  60hz Refresh Rate; 8-Bit Depth


This post has been edited by Doom64hunter: 24 December 2019 - 06:28 AM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #8

View PostDoom64hunter, on 24 December 2019 - 03:57 AM, said:

Tried doing this on Windows and the stacktrace doesn't really give me any useful information unfortunately.

Oh! Instead of the normal "bt" command, try "thread apply all bt".
0

#9

Okay I found the cause. For r8139 we see the following change in /source/duke3d/src/network.cpp:
@@ -84,13 +71,10 @@

 void Net_GetPackets(void)
 {
-    timerUpdate();
-    MUSIC_Update();
-    S_Update();
+#ifndef NETCODE_DISABLE
+    if (g_netServer == NULL && g_netClient == NULL)
+        return;

-    G_HandleSpecialKeys();
-
-#ifndef NETCODE_DISABLE
     if (g_netDisconnect)
     {
         Net_Disconnect();


Notice that the following 4 calls:
  • timerUpdate();
  • MUSIC_Update();
  • S_Update();
  • G_HandleSpecialKeys();

were previously outside the #ifdef that disables the networking code. This means that they would always be executed, even with the netcode disabled. However, they have been removed with this commit.
Note that Net_GetPackets() is called directly and indirectly in various locations inside the code, most importantly through the function gameHandleEvents().
In particular, the missing call to S_Update() is causing the issue I am experiencing. Adding it to the function gameHandleEvents() solves the problem.

I suggest you review this change and determine what other effects the removal of these calls could have had on the game.

This post has been edited by Doom64hunter: 25 December 2019 - 05:38 AM

2

#10

Testing indicates that this issue occurs in NBlood and Rednukem (both for Duke 3D and RR) as well.

I haven't been able to reproduce it in VoidSW or PCExhumed, though the latter has a one-time focus switch delay that is non-recurring after the intro has been viewed.
Furthermore, Ion Fury, despite running using the same engine code as Duke 3D, does not exhibit the problem.

In fact, I believe that the VOC sound file format may be related to the issue. Namely, I was able to observe the same problem in the AMC TC until I converted every VOC sound file into OGG.
After that, the focus switch delay ceased to exist. This would explain why Fury does not exhibit the problem, as all its sounds are in OGG format.

This post has been edited by Doom64hunter: 28 December 2019 - 12:19 PM

0

#11

View PostDoom64hunter, on 25 December 2019 - 05:34 AM, said:

Notice that the following 4 calls:
  • timerUpdate();
  • MUSIC_Update();
  • S_Update();
  • G_HandleSpecialKeys();

were previously outside the #ifdef that disables the networking code. This means that they would always be executed, even with the netcode disabled. However, they have been removed with this commit.
Note that Net_GetPackets() is called directly and indirectly in various locations inside the code, most importantly through the function gameHandleEvents().
In particular, the missing call to S_Update() is causing the issue I am experiencing. Adding it to the function gameHandleEvents() solves the problem.

I suggest you review this change and determine what other effects the removal of these calls could have had on the game.


Addendum: the logic inside these functions actually has no relation to the problem I am experiencing. The only reason why adding a call to S_Update() prevents the problem is because it contains a loop that slightly delays the call to handleevents().

Adding a small busy loop (of around 10'000 iterations) into the main loop of app_main() inside game.cpp prevents the bug as well. No idea why however.

This post has been edited by Doom64hunter: 29 December 2019 - 07:00 AM

0

#12

This is probably the last update from my side, but I think I was able to track down the source of the problem as far as Build's source code goes.

Namely, I believe that the problem originates from the call to `SDL_PollEvent(event)` inside the function `handleevents_pollsdl()` of the file `source/build/src/sdlayer.cpp`.
This function implicitly calls `SDL_PumpEvents()`, and it appears that if this function is called in rapid succession, it produces the window focus change delay problem described in this thread.

Decreasing the frequency at which `SDL_PumpEvents()` is called (through use of SDL_PeepEvents() and explicitly calling SDL_PumpEvents() beforehand) for me alleviates the issue.
However, the way SDL_PollEvents() is used right now seems to be the intended way to use the library function, thus I believe that the problem may actually be an internal SDL bug.

Best way to work around it would probably be to introduce a small artificial delay before the events are polled in the loop. That solves the issue for me.

Edit: This also applies to the NBlood family of ports by the way.

This post has been edited by Doom64hunter: 29 December 2019 - 02:20 PM

3

User is offline   bansheexyz 

#13

View Postdragon84, on 23 October 2019 - 12:51 PM, said:

Anyone else have this issue? I can't be the only one.. because this is a rather game - or would i say computer- breaking bug.


I have the issue as well. I'm on the latest version of Windows 10. When I updated eduke32 for the first time in a year, I started getting this problem of the program hanging on exit, and I can't even ctrl+alt+del out of it. My entire system hardlocks. It would also hang during gameplay, but enabling vsync seemed to reduce the gameplay hangs. What's weird about the hangs is that they didn't happen if I quit right away, they only happened if I had been playing a bit, like something cumulative was happening the longer I played. It's also always possible to wait the hangs out. If you sit there for 3 minutes, the program will eventually unhang and you'll get control of your computer back.

Lastly, it only happens on the classic renderer. If I switch to polymer, it doesn't happen.

This post has been edited by bansheexyz: 03 January 2020 - 12:02 PM

0

#14

View PostDoom64hunter, on 29 December 2019 - 11:25 AM, said:

This is probably the last update from my side, but I think I was able to track down the source of the problem as far as Build's source code goes.

Namely, I believe that the problem originates from the call to `SDL_PollEvent(event)` inside the function `handleevents_pollsdl()` of the file `source/build/src/sdlayer.cpp`.
This function implicitly calls `SDL_PumpEvents()`, and it appears that if this function is called in rapid succession, it produces the window focus change delay problem described in this thread.

Decreasing the frequency at which `SDL_PumpEvents()` is called (through use of SDL_PeepEvents() and explicitly calling SDL_PumpEvents() beforehand) for me alleviates the issue.
However, the way SDL_PollEvents() is used right now seems to be the intended way to use the library function, thus I believe that the problem may actually be an internal SDL bug.

Best way to work around it would probably be to introduce a small artificial delay before the events are polled in the loop. That solves the issue for me.

Edit: This also applies to the NBlood family of ports by the way.


One more update, here's the diff I used to do what I described in the above post:
Index: source/build/src/sdlayer.cpp
===================================================================
--- source/build/src/sdlayer.cpp        (revision 8534)
+++ source/build/src/sdlayer.cpp        (working copy)
@@ -2275,6 +2275,9 @@
     return 0;
 }

+static SDL_Event events[16384];
+static int cnt = 0;
+
 int32_t handleevents_pollsdl(void);
 #if SDL_MAJOR_VERSION != 1
 // SDL 2.0 specific event handling
@@ -2282,9 +2285,16 @@
 {
     int32_t code, rv=0, j;
     SDL_Event ev;
+    if (cnt++ == 0){
+        SDL_PumpEvents();
+    }
+    cnt = cnt % 1000;
+    int count = SDL_PeepEvents(events, 16384, SDL_GETEVENT, SDL_FIRSTEVENT, SDL_LASTEVENT);

-    while (SDL_PollEvent(&ev))
+    //while (SDL_PollEvent(&ev))
+    for (int event_cnt = 0; event_cnt < count; event_cnt++)
     {
+        ev = events[event_cnt];
         switch (ev.type)
         {
             case SDL_TEXTINPUT:


This uses SDL_PeepEvents() and SDL_PumpEvents() to replace the call to SDL_PollEvent() (which should be equivalent in function from what I gather).
The main difference is that I can control the frequency of calls to SDL_PumpEvents(), which is normally implicitly called by SDL_PollEvent(). This function is supposed to gather events from the input devices, such that they can then be retrieved using SDL_PeepEvents().
If I reduce the frequency of calls to 1 per 1000 iterations, then the problem as described in this thread no longer occurs.

Unlike adding a busy loop, this change does not significantly increase the time needed to process one iteration of the main loop, therefore I am fairly certain that the frequency of calls to this function is in fact the source of the issue.
Also worth mentioning is that SDL uses different 'PumpEvent' functions for different operating systems. This would explain why I was not able to reproduce the problem on Debian; the problem is likely specific to the Windows PumpEvent function.

Also, I have had one other user on the Blood discord, who had been struggling with crashes and slow context switches in NBlood for a while test the above change, and it solved the problem for them too.
The next step would be to debug this in SDL directly, and if it is reproducible using a simple test program, report the problem to the SDL developers. However I currently lack the know-how and time to do so.
0

#15

Fixed for me as of r8572.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options