This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: RuntimeError: not holding the import lock
Type: Stage: resolved
Components: Versions: Python 2.7
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: arigo, dmi.baranov, gregory.p.smith, iritkatriel, pitrou, sbt
Priority: normal Keywords:

Created on 2013-06-02 20:07 by arigo, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
x.py arigo, 2013-06-02 20:07 Bug
Messages (9)
msg190498 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2013-06-02 20:07
A new bug, introduced in recent Python 2.7 (2.7.3 passes, 2.7 trunk fails):

With the attached x.py, running "python -c 'import x'" fails with RuntimeError: not holding the import lock.

It occurs when doing a fork() while holding the import lock, if the child process imports more things (here distutils, could be anything) before finally trying to release the import lock (here by returning from the original 'import x').
msg190518 - (view) Author: Dmi Baranov (dmi.baranov) * Date: 2013-06-03 05:56
Looks like old history from issue 7242
msg190523 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2013-06-03 08:18
The bug is different, because it doesn't depend on details of the platform.
msg190526 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-06-03 09:18
> 2.7.3 passes, 2.7 trunk fails

Python 2.7.0, 2.7.2 and 2.6.8 all fail here.
Dmi is right: it starts failing at 4afc50d15544.
(note that Python 3 isn't affected)
msg190531 - (view) Author: Dmi Baranov (dmi.baranov) * Date: 2013-06-03 10:13
My system python-2.7.3 affected too:

python -c 'import sys;print(sys.version);import x'
2.7.3 (default, Aug  1 2012, 05:16:07) 
[GCC 4.6.3]
Traceback (most recent call last):
  File "<string>", line 1, in <module>
RuntimeError: not holding the import lock

$ uname -a
Linux d9frog9n-desktop 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:32:50 UTC 2012 i686 i686 i386 GNU/Linux

Armin, at which system/architecture you passing that case on 2.7.3?
msg190533 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-06-03 10:24
Forking as a side effect of importing a module is evil.  I think raising a RuntimeError is preferable to trying to make it Just Work.

But maybe one could do

    void
    _PyImport_ReInitLock(void)
    {
        if (import_lock != NULL) {
            import_lock = PyThread_allocate_lock();
            PyThread_acquire_lock(import_lock, WAIT_LOCK);
        }
        import_lock_thread = PyThread_get_thread_ident();
        _PyImport_ReleaseLock();
    }
msg190549 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2013-06-03 15:45
Indeed, no clue: it seems I don't get the error only on my system-installed 2.7.3 on Linux 32.  I do get it on any other Python I tried, like 2.6.x, or the system-installed 2.7.1 on Linux 64.  So it's not actually a new bug.
msg191527 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-06-20 15:40
See also #9573 and #15914.
msg381283 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-11-17 20:17
Closing as this is a python-2 only issue.
History
Date User Action Args
2022-04-11 14:57:46adminsetgithub: 62322
2020-11-17 20:17:23iritkatrielsetstatus: open -> closed

nosy: + iritkatriel
messages: + msg381283

resolution: out of date
stage: resolved
2013-06-20 15:40:26sbtsetmessages: + msg191527
2013-06-03 15:45:17arigosetmessages: + msg190549
2013-06-03 10:24:43sbtsetnosy: + sbt
messages: + msg190533
2013-06-03 10:13:02dmi.baranovsetmessages: + msg190531
2013-06-03 09:18:19pitrousetmessages: + msg190526
2013-06-03 08:18:46arigosetmessages: + msg190523
2013-06-03 05:56:31dmi.baranovsetnosy: + gregory.p.smith, dmi.baranov
messages: + msg190518
2013-06-02 20:34:53amaury.forgeotdarcsetnosy: + pitrou
2013-06-02 20:07:13arigocreate