I did a search and find the issue 1947, however it's set to "not a bug". In its last note, it's suggested a 'packaging/environment issue'. But since I can reliably reproduce the issue with the "official python package"(that installed by the system, such as I am not building the python from source), Also, the same issue does not occurred on python 2.6.2, but 3.4.3 and 3.5.1. Even though it seems the "AssertionError" message is non-harmful but it's still a bit annoying. I am wondering if you can take a look my issue?

Please compile the attached source codes to reproduce my issue. Note that it only occurred when we (explicitly or implicitly) import the 'threading' module. If we comment out that line, it works fine.

This is how I compile my code:
CFLAG is obtained from `python3.5m-config --includes`
LDFLAG is obtained from `"python-3.5m-config --ldflags`
g++ ${CFLAG} ${LDFLAG} test2.C 

I am running on Linux.

After your `import threading` line, try `print(threading.__file__)`.  The path should be something like `/usr/local/lib/python3.4/threading.py`; if it's not (particularly if the current directory is part of the path), you've found the source of your problem, and you should move/rename the extra threading.py, as suggested by Brandon in msg144004.

I am seeing an AssertionError, but no AttributeError. In your original post you did mention AssertionError, but that contradicts the report title. Please clarify what the problem is.

$ CFLAG="$(python3.5m-config --includes)"
$ LDFLAG="$(python3.5m-config --ldflags)"
$ g++ ${CFLAG} ${LDFLAG} test2.C
$ ./a.out
['/home/proj/python/lib', '/usr/lib/python35.zip', '/usr/lib/python3.5', '/usr/lib/python3.5/plat-linux', '/usr/lib/python3.5/lib-dynload', '/home/.local/lib/python3.5/site-packages', '/usr/lib/python3.5/site-packages']
Exception ignored in: <module 'threading' from '/usr/lib/python3.5/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 1292, in _shutdown
    assert tlock.locked()
AssertionError:

I print out the threading.__file__ and can see it's "${PYTHONHOME}/lib/python3.5/threading.py" . I don't have any other "threading.py" elsewhere. so what should I do?

sorry Martin, you are right, my original title was simply (and wrongly) copied over from the issue 1947. You get my identical error message in your post.

I just update the title to be precise.
Exception ignored in: <module 'threading' from ...threading.py> in _shutdown, assert tlock.locked()
AssertionError:

So there is actually no relation to #1947.

I quote the "issue 1947" just because I did a search in the db before I file this issue and find its output is similar to what I see, (except that it has "AttributeError" which mine does not have.) and because it's filed for 2.5 and I am not sure if this is just some minor "wording changes".

I tend to believe my issue is not the same issue with 1947 now.

It looks like there is a bug in the _shutdown function of threading.py, that it does not check whether the _main_thread.is_alive() or not.  My temporary fix is to add the following checking in the beginning of _shutdown and it seems no more error message pop up:

if( _main_thread.is_active() is False ):
  return

Please see if this makes sense.

sorry typo above, is_active should be read as is_alive.

Hi Pitrou, 

would you be able to look at my issue and the proposed pathc?

Thanks

seems we also need to check whether _main_thread is daemon thread or not, so the proposed patch would look like:

def _shutdown():
   # add these checking first
   if( _main_thread.isDaemon() is False or _main_thread.is_alive() is False ):
       return

Extract of test2.C:
---
  // in main thread
  Py_Initialize();
  PyEval_InitThreads();
  PyEval_SaveThread();

  // creating a new sub-interpreter, in my real app, this would be created
  //   in a sub-thread.
  PyInterpreterState* const mainInterpreterState = PyInterpreterState_New();
  PyThreadState* const taskState = PyThreadState_New(mainInterpreterState);
  PyEval_AcquireThread(taskState);
  PyThreadState * const sub_interp = Py_NewInterpreter();
  PyThreadState_Swap( taskState );
  PyEval_ReleaseThread( taskState );
---

IMO this code is not supported. It creates 3 interpreters:

* Py_Initialize(): good
* PyInterpreterState_New(): partially initialized
* Py_NewInterpreter(): created from the partially initialized interpreter

IMHO PyInterpreterState_New() should never be used outside Python internals. Only Py_NewInterpreter() should be used.

At least, this code now fails since PyInterpreterState_New() configuration (interp->config) is empty/uninitizalized, and so _PySys_InitMain() fails.

Moreover, the example uses PyGILState C API which isn't compatible with subinterpreters yet :-(

Can we close this as not a bug, as the reproducer includes unsupported code?

Yeah, I consider that the issue can be closed.

I'm ok to investigate the issue if another reproducer code is written only using fully initialized (sub)interpreters.