[Bug] Debugger doesnt return to command line when using RobotCode in combination with ScreenCapLibrary

[Daniwin82]

SUMMARY: When using the robotcode extension, RF doesn't return to the commandline after finishing a testcase. RF: 4.1.3 and 6.0.2 extension version: 0.28.2

SCENARIO: Install ScreenCapLibrary Add 'Start Video Recording' to the TestSetup Add 'Stop Video Recording' to the TestTearDown Run a simple testcase logging something

RESULT:

• RF log and report get created (OK)
• WEBM-file (video) files get created (OK)
• It doesnt return to the command line. (NOT OK, see picture)
• when trying to start a 2nd test run, it say 'Can't connect to debugger' (see picture)

[d-biehl]

ok, I checked and found out that the ScreenCapLibrary is deleting the running ThreadPoolExecutor queues from the Python interpreter.

see here: https://github.com/rticau/ScreenCapLibrary/blob/146304edac5a062a39f6c738a0516212acbd0197/src/ScreenCapLibrary/client.py#L37 and here https://github.com/rticau/ScreenCapLibrary/blob/146304edac5a062a39f6c738a0516212acbd0197/src/ScreenCapLibrary/client.py#L252

This worked under Python 3.8, because the thread queues were still daemon threads. Daemon threads are simply killed by Python on shutdown.

In new Python version it is tried to shutdown these ThreadPoolExecutor threads reasonable, but because the list of ThreadPoolExecutor threads is empty now, because it is deleted by the ScreenCap library, there are still threads running in the background, which are not terminated correctly. That's why the debugger hangs, because it also runs ThreadPoolExecutor, but since Python doesn't know that it exists anymore, it won't be terminated.

From my point of view this must be corrected in the ScreenCapLibrary, because it not only affects the RobotCode debugger, but probably also other libraries, I know that the BrowserLibrary also uses ThreadpoolExecutors.

I would prefer not to implement a workaround only for a library that hacks the Python interpreter ;-)

I created an issue in the ScreenCapLibrary project, let's see what happens.

A workaround at the moment is to hack ScreenCapLibrary, just change this line: https://github.com/rticau/ScreenCapLibrary/blob/146304edac5a062a39f6c738a0516212acbd0197/src/ScreenCapLibrary/client.py#L252

like this:

    @staticmethod
    def clear_thread_queues():
        # _threads_queues.clear()
        pass

[Daniwin82]

Hi Daniel,

Thanks for investigating the issue and for providing a workaround!

Daniel

[d-biehl]

@Daniwin82 Till now I have no answer from the screencaplibrary project, seems a little bit dead. What is your solution? did you make a fork of the project? Can I close this issue?

[Daniwin82]

@d-biehl,

I applied the solution you provided locally. Works for me. I guess this issue can be closed.

Daniel

[d-biehl]

ok, thanks for feedback!

and maybe you can give this issue a thump up https://github.com/rticau/ScreenCapLibrary/issues/84