UnboundLocalError: local variable 'self' referenced before assignment

[sentry-for-tribler]

Sentry Issue: TRIBLER-1JA

UnboundLocalError: local variable 'self' referenced before assignment
(1 additional frame(s) were not displayed)
...
  File "ipv8\taskmanager.py", line 131, in done_cb
  File "ipv8\taskmanager.py", line 18, in interval_runner
  File "tribler\core\components\libtorrent\download_manager\download_manager.py", line 828, in _invoke_states_cb
  File "tribler\core\components\libtorrent\download_manager\download_manager.py", line 839, in sesscb_states_callback
  File "tribler\core\components\libtorrent\torrentdef.py", line 236, in get_infohash

[drew2a]

Yesterday, @kozlovsky expressed suspicion that the issue could be related to the old Python version (3.8.4) used on our builder machines.

Perhaps it's a good time to upgrade it to 3.9?

@xoriole, is it easy to change the Python version on our builders? I can manage the change for GitHub actions.

Ref:

• https://stackoverflow.com/questions/51964883/keras-and-tensorflow-unboundlocalerror-local-variable-self-referenced-before

[xoriole]

@drew2a I can try upgrading the builders today to 3.9.
For 3.10, we have a blocker.

[sentry-for-tribler]

Sentry issue: TRIBLER-1JT for 7.13.1

[
Traceback (most recent call last):, 
  File "asyncio\events.py", line 81, in _run, 
  File "asyncio\proactor_events.py", line 162, in _call_connection_lost, 
OSError: [WinError 10038] Сделана попытка выполнить операцию на объекте, не являющемся сокетом
]

[kozlovsky]

The last linked Sentry issue shows another unrelated case of UnboundLocalError:

UnboundLocalError: local variable 'exc_info' referenced before assignment
  File "tribler\core\components\libtorrent\download_manager\download.py", line 248, in process_alert
  File "tribler\core\components\libtorrent\download_manager\download.py", line 325, in on_tracker_error_alert
  File "__init__.py", line 1463, in error
  File "__init__.py", line 1570, in _log

Here, the error happens inside the code of the logging library:

    def _log(self, level, msg, args, exc_info=None, extra=None, stack_info=False,
             stacklevel=1):
        """
        Low-level logging routine which creates a LogRecord and then calls
        all the handlers of this logger to handle the record.
        """
        sinfo = None
        if _srcfile:
            #IronPython doesn't track Python frames, so findCaller raises an
            #exception on some versions of IronPython. We trap it here so that
            #IronPython can use logging.
            try:
                fn, lno, func, sinfo = self.findCaller(stack_info, stacklevel)
            except ValueError: # pragma: no cover
                fn, lno, func = "(unknown file)", 0, "(unknown function)"
        else: # pragma: no cover
            fn, lno, func = "(unknown file)", 0, "(unknown function)"
        if exc_info:  # <-- UnboundLocalError: local variable 'exc_info' referenced before assignment

The only reasonable explanation of how this can happen is memory corruption by a misbehaving C++ code.

Note that the error is inside the process_alert call. That looks suspicious because incorrect handling of ltsession.pop_alerts() is a possible reason for memory corruption (see #7886).

[kozlovsky]

Another error:

SystemError: PyEval_EvalCodeEx: NULL globals
  File "asyncio\proactor_events.py", line 526, in _loop_writing
  File "asyncio\windows_events.py", line 522, in sendto
  File "asyncio\windows_events.py", line 734, in _register

Traceback is different, but the underlying reason should be the same: memory corruption

[kozlovsky]

There is a chance #7945 can fix this problem. If not, then it is most probably libtorrent-related. My hope is that upgrading to Python 3.10, that is now possible, can fix the root reason of memory corruption problems.

[github-actions]

This issue has not seen activity for 60 days. It is now marked as stale. Please provide additional information or this issue may be closed in the future. We value your contribution and would love to hear more!

[qstokkink]

The newest build implementation is now using Python 3.10. Looking at this discussion, this should be enough to resolve the various concerns listed here.