"list index out of range" if vulkaninfo not installed

[Oliver Hill]

Describe the bug

Attempting to use jtop (specifically the python API) if vulkaninfo is not installed throws a "list index out of range" error. Presumably this is because which vulkaninfo returns an empty string, so attempting to call vulkaninfo later calls popen with empty args, prompting the list index out of range.

Note that as far as I can tell, the API still works correctly and reports the values I'm after, it just throws this exception frequently without actually causing the entire thing to fail.

Full stack trace:

Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.8/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/snap/q-bot-spraying-robot/x50/lib/python3.8/site-packages/jtop/jtop.py", line 123, in _load_jetson_libraries
    os_variables = get_libraries()
  File "/snap/q-bot-spraying-robot/x50/lib/python3.8/site-packages/jtop/core/jetson_libraries.py", line 115, in get_libraries
    lines = cmd_vulkan()
  File "/snap/q-bot-spraying-robot/x50/lib/python3.8/site-packages/jtop/core/command.py", line 111, in __call__
    raise ex_value
  File "/snap/q-bot-spraying-robot/x50/lib/python3.8/site-packages/jtop/core/command.py", line 76, in target
    self.process = sp.Popen(self.command, stdout=sp.PIPE, stderr=sp.PIPE, stdin=open(os.devnull), preexec_fn=os.setsid)
  File "/usr/lib/python3.8/subprocess.py", line 858, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.8/subprocess.py", line 1580, in _execute_child
    executable = args[0]
IndexError: list index out of range

Solution

Obviously it would be preferable to have vulkaninfo installed - I don't in this case because I'm using the jtop python API within a snap without explicitly installing vulkaninfo. Perhaps it should be added as an explicit dependency (e.g. in requirements.txt)?

Regardless, since other fail cases are handled with a simple pass, it seems reasonable to check if cmd_vulkaninfo is empty before calling it, or catch the list index exception in the except block, and continue without failure.

[Raffaello Bonghi]

Hi @Ecophagy

Thank you for your issue. I'm trying to reproduce your issue on my device, but even if I don't install Vulkan I don't face the same bug.

I'm running this script:

from jtop import jtop

with jtop() as jetson:
    # boards
    print('*** board ***')
    print(jetson.board) 

Do you have a different setup?

[Oliver Hill]

Hi rbonghi,

I do have different setup - I am running my jtop inside a snap. Unfortunately, it is proving non-trivial to create an example at the moment.

I did also try your example on my Jetson Nano with vulkaninfo explicitly uninstalled, and could also not reproduce the issue.

However, running ps.Popen with an empty list process = sp.Popen([], stdout=sp.PIPE, stderr=sp.PIPE, stdin=open(os.devnull), preexec_fn=os.setsid) does reproduce the issue - throwing the expected exception:

Traceback (most recent call last):
  File "./jtop-test.py", line 9, in <module>
    process = sp.Popen([], stdout=sp.PIPE, stderr=sp.PIPE, stdin=open(os.devnull), preexec_fn=os.setsid)
  File "/usr/lib/python3.8/subprocess.py", line 858, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.8/subprocess.py", line 1580, in _execute_child
    executable = args[0]
IndexError: list index out of range

And running

out = []
process = sp.Popen(['which', 'vulkaninfo'], stdout=sp.PIPE, stderr=sp.PIPE, stdin=open(os.devnull), preexec_fn=os.setsid)
for line in iter(process.stdout.readline, b''):
        out.append(line)
print(out)

does indeed output an empty list.

So exactly why it's not happening when we run jtop is a mystery, but I think which vulkaninfo not returning a path when vulkaninfo is not installed is still the area of the issue.

EDIT: Did some digging, and it looks like if which can't find the program, the return code is non-zero. So Command should be catching it and throwing a CommandException. So I can't actually see how my exception could have happened in the first place!

[Raffaello Bonghi]

I found a fix for this strange bug :-)

Here my patch: 8f56f70

I'll keep you posted when will be merge in a new release

[Oliver Hill]

Yup, that looks like it would solve the issue. Thanks for looking in to it!