RuntimeError: Access violation - no RTTI data!

[sentry-for-tribler]

Sentry Issue: TRIBLER-1JG

RuntimeError: Access violation - no RTTI data!
  File "asyncio\events.py", line 81, in _run
  File "ipv8\taskmanager.py", line 131, in done_cb
  File "ipv8\taskmanager.py", line 18, in interval_runner
  File "ipv8\util.py", line 35, in call_async
  File "tribler\core\components\libtorrent\download_manager\download_manager.py", line 538, in _task_process_alerts

[drew2a]

    def _task_process_alerts(self):
        for hops, ltsession in list(self.ltsessions.items()):
            if ltsession:
                for alert in ltsession.pop_alerts():  # error has been raised here
                    self.process_alert(alert, hops=hops)

RTTI = Run Time Type Information.

pop_alerts documentation: https://libtorrent.org/reference-Session.html#pop_alerts()

Alerts is the main mechanism for libtorrent to report errors and events. pop_alerts fills in the vector passed to it with 
pointers to new alerts. The [session](https://libtorrent.org/reference-Session.html#session) still owns these alerts and 
they will stay valid until the next time pop_alerts is called. You may not delete the 
[alert](https://libtorrent.org/reference-Alerts.html#alert) objects.

A user has removed a torrent just before the crash:

Request: DELETE http://localhost:50729/downloads/<hash>
Finished: DELETE http://localhost:50729/downloads/<hash>
Request: GET http://localhost:50729/downloads?get_pieces=1
Finished: GET http://localhost:50729/downloads?get_pieces=1
CoreExceptionHandler.unhandled_error_observer(): RuntimeError: Access violation - no RTTI data!

So, I can identify two probable causes of the error:

1. An alert from a previous pop_alerts call is being modified/accessed during the current call of pop_alerts.
2. The information about the sessions becomes outdated during the _task_process_alerts since it caches the session list:

    def _task_process_alerts(self):
        for hops, ltsession in list(self.ltsessions.items()):   # <- here
            ...

[drew2a]

I couldn't find a way to properly fix the error besides addressing it through #7940, which fixes potentially dangerous situations but is not the root cause of the original issue. Therefore, I'm unassigning myself from it.