Plamen Dimitrov

I experienced the same thing, it is a complete blocker for using the CLI on recent Fedora machines.

Hi @willianrampazzo, I was in the conversation too so to add my 2 cents here: I would recommend contributing this PR or anything that is not already implemented to https://github.com/avocado-framework/aexpect.

@clebergnu @beraldoleal @richtja I just had another trouble like this: an imported library that is used in the tests needed to use stderr in ``` [stdlog] 2022-06-28 11:08:07,666 avocado.test ERROR|...

> @pevogam I think you are on the right track. This was an almost unsolvable problem with the legacy runner, because of its forking/execing model. > > Now with `nrunner`,...

Sorry, this is a remnant from `gdb`, it shouldn't be related to the stack trace in any way. I thought I cleaned up these lines when copying but will do...

To add some more background: This issue can happen on different tests and independently of the hardware load. It is thus not 100% reproducible but highly probable in tests involving...

Another strack trace I obtained just now: ``` File "/usr/lib64/python3.9/multiprocessing/synchronize.py", line 95, in __enter__ return self._semlock.__enter__() File "/usr/lib64/python3.9/multiprocessing/queues.py", line 377, in put with self._wlock: File "/usr/lib/python3.9/site-packages/avocado/core/runners/utils/messages.py", line 176, in write...

I think I have hit here is a very special circumstance, described well here: https://codewithoutrules.com/2017/08/16/concurrency-python/ The crux of the problem is in the mix of `queue`, garbage collection, and the...

Here are some of the stack traces I have collected from different runs with explanation for what happened in each: ``` Traceback (most recent call first): File "/usr/lib64/python3.9/multiprocessing/synchronize.py", line 95,...

@clebergnu @richtja I have noticed you are using `SimpleQueue` for this on the Avocado (instrumented tests) and Avocado VT sides which is supposed to be fixed after Python 3.7 and...