Enabling `trace on` creates erroneous traceback

[gnikit]

xonfig

+------------------+-----------------+
| xonsh            | 0.13.1          |
| Python           | 3.10.5          |
| PLY              | 3.11            |
| have readline    | True            |
| prompt toolkit   | 3.0.30          |
| shell type       | prompt_toolkit  |
| history backend  | json            |
| pygments         | 2.13.0          |
| on posix         | True            |
| on linux         | True            |
| distro           | unknown         |
| on wsl           | False           |
| on darwin        | False           |
| on windows       | False           |
| on cygwin        | False           |
| on msys2         | False           |
| is superuser     | False           |
| default encoding | utf-8           |
| xonsh encoding   | utf-8           |
| encoding errors  | surrogateescape |
| xontrib          | []              |
| RC file          | []              |
+------------------+-----------------+

Expected Behavior

No exception and traceback in the output

Current Behavior

When setting trace on an exception is raised and a traceback is produced

Traceback (if applicable)

Exception ignored in: <function _removeHandlerRef at 0x7f6872497f40>
Traceback (most recent call last):
  File "/home/gn/anaconda3/envs/xonsh/lib/python3.10/logging/__init__.py", line 836, in _removeHandlerRef
  File "/home/gn/anaconda3/envs/xonsh/lib/python3.10/site-packages/xonsh/tracer.py", line 87, in trace
TypeError: 'NoneType' object is not callable

Steps to Reproduce

Any MWE with using trace on e.g. run the following xonsh test.xsh

$cat test.xsh
#!/usr/bin/env xonsh

$XONSH_TRACE_SUBPROC = True
trace on

echo "OK"

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

[yaxollum]

Hi @gnikit ! I can't reproduce this issue on Arch Linux running python 3.10.5 with xonsh 0.13.1 (installed using pip).

Could you please provide some more details on your specific environment (e.g. how you installed xonsh)?

[gnikit]

I installed using Anaconda through conda forge in a new venv. e.g.

conda create -n xonsh -c conda-forge xonsh

environment.yml

name: xonsh
channels:
  - defaults
  - conda-forge
dependencies:
  - _libgcc_mutex=0.1=conda_forge
  - _openmp_mutex=4.5=2_gnu
  - backports=1.0=py_2
  - backports.functools_lru_cache=1.6.4=pyhd8ed1ab_0
  - bzip2=1.0.8=h7f98852_4
  - ca-certificates=2022.6.15=ha878542_0
  - colorama=0.4.5=pyhd8ed1ab_0
  - conda-suggest=0.1.1=pyh9f0ad1d_0
  - conda-suggest-conda-forge=2021.8.24=ha770c72_0
  - ld_impl_linux-64=2.36.1=hea4e1c9_2
  - libffi=3.4.2=h7f98852_5
  - libgcc-ng=12.1.0=h8d9b700_16
  - libgomp=12.1.0=h8d9b700_16
  - libnsl=2.0.0=h7f98852_0
  - libsqlite=3.39.2=h753d276_1
  - libuuid=2.32.1=h7f98852_1000
  - libzlib=1.2.12=h166bdaf_2
  - ncurses=6.3=h27087fc_1
  - openssl=3.0.5=h166bdaf_1
  - pip=22.2.2=pyhd8ed1ab_0
  - prompt-toolkit=3.0.30=pyha770c72_0
  - prompt_toolkit=3.0.30=hd8ed1ab_0
  - pygments=2.13.0=pyhd8ed1ab_0
  - pyperclip=1.8.2=pyhd8ed1ab_2
  - python=3.10.5=ha86cf86_0_cpython
  - python_abi=3.10=2_cp310
  - readline=8.1.2=h0f457ee_0
  - setproctitle=1.3.2=py310h5764c6d_0
  - setuptools=65.1.0=py310hff52083_0
  - sqlite=3.39.2=h4ff8645_1
  - tk=8.6.12=h27826a3_0
  - tqdm=4.64.0=pyhd8ed1ab_0
  - tzdata=2022c=h191b570_0
  - wcwidth=0.2.5=pyh9f0ad1d_2
  - wheel=0.37.1=pyhd8ed1ab_0
  - xonsh=0.13.1=py310hff52083_0
  - xz=5.2.6=h166bdaf_0

$uname -a
Linux gn 5.4.0-122-generic #138-Ubuntu SMP Wed Jun 22 15:00:31 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

I hope this helps a bit @yaxollum. It would appear that in our CI we don't get the errors anymore, but I am still able to replicate it locally with the conda packages I provided.

[yaxollum]

Thanks for the information! I was able to reproduce this issue after installing xonsh through Anaconda.

[yaxollum]

There seems to be an issue with the shutdown procedure of the tracer, because when I add a trace off to the end of test.xsh, no error message is produced.

[vedantroy]

Also running into this issue for xonsh version 0.13.3.