IndexError: tuple index out of range

[AlexWhitehouse]

As title, index error occurs randomly and UI is scrambled between graphs and the error.

Resizing the window or pressing any key returns the UI to normal and removes the error

[excurso]

I don't have this IndexError, but sometimes when I start nyx, it looks similar to your screenshot.

Ctrl+C shows the following call stack:

Traceback (most recent call last):
  File "/usr/bin/nyx", line 33, in <module>
    sys.exit(load_entry_point('nyx==2.1.0', 'console_scripts', 'nyx')())
  File "/usr/lib/python3/dist-packages/nyx/__init__.py", line 176, in main
    nyx.starter.main()
  File "/usr/lib/python3/dist-packages/stem/util/conf.py", line 289, in wrapped
    return func(*args, config = config, **kwargs)
  File "/usr/lib/python3/dist-packages/nyx/starter.py", line 133, in main
    _shutdown_daemons(controller)
  File "/usr/lib/python3/dist-packages/nyx/starter.py", line 254, in _shutdown_daemons
    controller.close()
  File "/usr/lib/python3/dist-packages/stem/control.py", line 1103, in close
    super(Controller, self).close()
  File "/usr/lib/python3/dist-packages/stem/control.py", line 753, in close
    t.join()
  File "/usr/lib/python3.10/threading.py", line 1096, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.10/threading.py", line 1116, in _wait_for_tstate_lock
    if lock.acquire(block, timeout):
KeyboardInterrupt

Also sometimes when I leave nyx, it hangs.

Seems to be a multithreading issue. Deadlock probably...

[chiploonkar]

I have the same problem - and resizing seems to fix it temporarily. Additionally, I no longer have the connections page showing active connections, though I'm not sure if it's related.

[mzpqnxow]

Appears to be a race condition causing the exception as others conjectured, caused by the way the sqlite connection is locked

I think the issue is that sqlite needs the fetchall() / fetchone() calls to be under lock, not only the execute()

The _query() method implements the lock currently, it effectively locks the execute() method:

def _query(self, query, *param):
    """
    Performs a query on our cache.
    """

    with self._conn_lock:
        return self._conn.execute(query, param)

The lock is released after execute()

The callers of the _query() method then call the
fetchall() or fetchone() methods to retrieve the results. These methods must also be locked to be safe, but are not.

To fix, you could:

• Remove the _query() method
• Add a _query_fetchall() and _query_fetchone()
• The body of each should be locked in the way _query() was
• They should return .query(...).fetchall() or .query(...).fetchone() respectively
• Update each call to self._query(...).fetch with self._query_fetch()

You would have something like this, and would replace the lines currently using fetchall()/fetchone() directly with calls to these methods:

def _query_fetchall(self, query, *param):
    """
    Performs a query on our cache.
    """

    with self._conn_lock:
        return self._conn.execute(query, param).fetchall()

def _query_fetchone(self, query, *param):
    """
    Performs a query on our cache.
    """

    with self._conn_lock:
        return self._conn.execute(query, param).fetchone()

There are a few different ways to do it, that seems easiest to me

I don't have a system that uses nyx (or tor, for that matter) so I can't really test this. But maybe this is helpful for someone who wants to test/send a PR