Erratic hangs on quit under Windows

[Hentai Senshi]

On my current projects (TentaclePipes and Yuri no Yume), I've been doing some of the development under Win2K. Sometimes, when I quit the game (whether from the close box or the menu) it will deadlock - Windows says the process is busy and only allows it to quit using 'End Task', and it doesn't update the screen. If it has once deadlocked upon quit, it will continue to do so until a reboot.

And, most annoyingly, there doesn't seem to be any predictable way to reproduce the bug - sometimes everything will work fine (like right now).

(Edit - this was on 6.3.3. I've tried to reproduce it under 6.4.0, but it refuses to reproduce under either at the moment.)

[Hentai Senshi]

The hang-on-quit bug happened again.

As before, quitting and restarting the launcher did not fix it. Neither did moving it over to 6.4.0
(It had been 6.3.3). Filemon showed that the last action renpy attempted before deadlocking was trying to close the persistent file.

Changing video mode to 1024x768 (It had been 1280x1024) did fix it, and it was still okay when I
went back to 1280x1024; I suspect something is leaking in video memory handling - no idea if the
leak's in renpy or elsewhere. (Also, while installing I noticed that this is still an unpatched win2K - I should get SP4.)

Has anyone else encountered the hang-on-quit bug? Is anyone else using renpy under Win2K?

[PyTom]

Hm... this is a tough one.

I need you to do the following to try to locate where the error is occuring:

edit the file renpy-6.4.0/renpy/bootstrap.py. In it, you'll find the lines:

Code: Select all

    options, args = op.parse_args()

    if options.trace:
        enable_trace(options.trace)

change these to read:

Code: Select all

    options, args = op.parse_args()

    options.trace = 1

    if options.trace:
        enable_trace(options.trace)

Ren'Py should create a file, "trace.txt", that shows what code is executing. If you can run the game until it crashes, and then send me trace.txt, then I can try debugging from that.

Thanks.

[Adorya]

After checking the matrix function, I had a "crash" with current renpy version when I exit it:
- Screen black but only the mouse can be seen, and can move/click but nothing appear
- Had to manually enter the screen resolution setup with my "blindness" (glad I knew how to reach it with the correct keyboard key sentences) and set up the depth color (32 bits to 16 bits)
- The problem is, whenever now I try to go back to the original settings (1024x768, 32 bits), the screen go black again, so I need to reboot.

note : I launch renpy using the old ctrl+0 setting from Scite.

edit again : seems to be I can't reproduce this bug again, I ran again renpy and it exited normally on the original setting. The trace option didn't say anything since there was no crash involved.

edit 3 : ouch, no wonder the trace feature is disabled, it take at least 50 Mo of log file to just run the launcher

[Hentai Senshi]

Hm... this is a tough one.

I need you to do the following to try to locate where the error is occuring:

edit the file renpy-6.4.0/renpy/bootstrap.py. In it, you'll find the lines:

Code: Select all

    options, args = op.parse_args()

    if options.trace:
        enable_trace(options.trace)

change these to read:

Code: Select all

    options, args = op.parse_args()

    options.trace = 1

    if options.trace:
        enable_trace(options.trace)

Ren'Py should create a file, "trace.txt", that shows what code is executing. If you can run the game until it crashes, and then send me trace.txt, then I can try debugging from that.

Thanks.

Okay, here it is.

This trace was made with a GameMaker game running at the same time - at the moment, my suspicion is that ren'py or SDL are deadlocking when video memory is exhausted, and running GM games exposes the bug because GM doesn't free video memory; I've seen it happen even after I've quit the GM game in question, though.

[PyTom]

Hm... annoyingly, the trace gets cut off right in the middle of a line.

Could you change bootstrap.py again? Add a line after:

Code: Select all

    print >>trace_file, fn, frame.f_lineno, frame.f_code.co_name, event

so it reads:

Code: Select all

    print >>trace_file, fn, frame.f_lineno, frame.f_code.co_name, event
    trace_file.flush()

This way, it will write the file out to disk before it can crash.

I'm not sure why SDL would deadlock when video memory is exhausted. We run the thing in the most conservative mode possible... just ask the OS to blt an image to the screen for us, everything should be done automatically after that.

Hopefully, once I get a physical Windows box (in another few weeks), I'll be able to repeat this... it's tough to debug something you can't repeat.

[Hentai Senshi]

Okay, here's another one.

[PyTom]

Okay, so we're making it all the way through to a normal shutdown. The last call is to disable_mixer, which is normal... I'm willing to believe that's completing properly, although it could potentially be an issue. (Does the problem come back with all of the mixers set to zero?)

Hm... I need to look at things in a debugger under windows, so I can sort out what's going wrong.

[Hentai Senshi]

Okay, so we're making it all the way through to a normal shutdown. The last call is to disable_mixer, which is normal... I'm willing to believe that's completing properly, although it could potentially be an issue. (Does the problem come back with all of the mixers set to zero?)

I killed the program with control-alt-delete, so there's a possibility that that forced its way to a normal shutdown. Will check the mixers next time I'm in Windows (the test machine doesn't have speakers, so I wouldn't notice it.) - should I upload a log before control-alt-deling the next time it happens?

[Hentai Senshi]

Okay, so we're making it all the way through to a normal shutdown. The last call is to disable_mixer, which is normal... I'm willing to believe that's completing properly, although it could potentially be an issue. (Does the problem come back with all of the mixers set to zero?)

The mixers don't seem to be changed.

I went back and looked at the trace file without killing the program first and it still ends with

Code: Select all

main.py 31 save_persistent call
copy_reg.pyo 58 _reduce_ex call
game.py 88 __getstate__ call
copy_reg.pyo 58 _reduce_ex call
copy_reg.pyo 58 _reduce_ex call
sets.pyo 431 __getstate__ call
copy_reg.pyo 58 _reduce_ex call
sets.pyo 431 __getstate__ call
copy_reg.pyo 58 _reduce_ex call
sets.pyo 431 __getstate__ call
zlib_codec.pyo 14 zlib_encode call
atexit.pyo 11 _run_exitfuncs call
audio.py 83 disable_mixer call

So disable_mixer isn't being called in the force quit response.