[8.0ß5-x64] Crash on quick Esc after closing nag screen

[Flint]

1. Start an unregistered copy of TC with non-existent INI located in a read-only place (e.g. Windows or Program Files if you are not Admin). Wait for the nag screen to appear.
2. Press the appropriate 1-2-3 key and very quickly after it press Esc.
3. If keypresses are quick enough, the Configuration dialog appears (Esc must be pressed too early to close this dialog).
4. Close the dialog by pressing Esc again.
5. TC crashes with the following stack trace:

Code: Select all

---------------------------
Total Commander 8.0ß5
---------------------------
Access violation.
Access violation
Windows 7 SP1 6.1 (Build 7601)

Please report this error to the Author, with a description
of what you were doing when this error occurred!

Stack trace (x64):A68270
528405 6A59DF 68E24C 7C4282 7B887B 437533 89FCCF 7F5858
8A89C5 76CA9BD1 
Press Ctrl+C to copy this report!
Continue execution?
---------------------------
Yes   No   
---------------------------

[ghisler(Author)]

Thanks, I will analyze your report. So far I couldn't reproduce the crash, the configuration dialog always disappears immediately...

[Flint]

So far I couldn't reproduce the crash, the configuration dialog always disappears immediately...

I reproduced it in a virtual machine with Aero turned on. Aero works more slowly there than on host, so maybe it's worth trying, or even slow down the virtual machine itself (in latest VirtualBox release there is an option for that; don't know about VMware).

[ghisler(Author)]

Unfortunately I can't reproduce it even when I put a Sleep(1000) command in the function which reacts to 1-2-3. I have now put a try...except block around the crash location, but that's just fighting against the symptoms. I have no idea how to reproduce this error, sorry.

[Flint]

ghisler(Author)
OK, in 8.0β6 the crash does not occur. I think it may be left with this try..except wrapping. If you wish to find the real source of the problem just let me know, I'm ready to help: record a video, run test builds of TC for debugging purposes, etc.

[ghisler(Author)]

I don't think it's worth the troubles, because most users will not encounter it. Therefore this pseudo fix is probably sufficient.

[Flint]

Just out of interest: could this old problem be caused by the fact that TC opened two Configuration dialogs, as you wrote here? I tried to reproduce the scenario described in the first post and found out that Esc now always closes the Configuration dialog, so step 3 became impossible and the whole scenario unreproducible.

So what I think happened earlier: after closing the nag screen, TC opened two Configuration dialogs. If I waited for some time and only then pressed Esc, TC had enough time to initialize and show both copies of the dialog, and when processing Esc TC closed them both. But if I pressed Esc too early, TC opened the first dialog, then processed Esc which closed this first dialog, and only then the second copy of the dialog arrived — the one I could see on the step 3. And closing this second copy corrupted some internal data.

Now that you fixed the bug with creating two dialogs, maybe, this problem also became resolved, and temporary workaround with try..excepd can be got rid of. If you think this idea is worth checking, you can count on me.

[ghisler(Author)]

Interesting indeed - yes, please test it, I still can't reproduce this problem here...

[Flint]

yes, please test it

If you would provide a test build without try..except… As I said, I already tried to reproduce the problem in rc2, but I cannot tell whether TC works fine because of the mentioned bugfix, or because the exception is intercepted and suppressed, as you implemented it earlier.

[ghisler(Author)]

I see - if you don't get any crash, I don't see a reason to check this now without try..except.