Skip to content

multiprocessing.get_logger() logger deadlock on first call by subprocess to logger.info("...") due to internal logger.debug(...) call by multiprocessing.Queue._start_thread #91555

Closed
@AshleyT3

Description

@AshleyT3

Python: v3.10.2
Platform: Windows 10

Description: A deadlock occurs when a subprocess uses a logging.Logger returned multiprocessing.get_logger() where the initial logging level at the time of the first call to logger.info is level DEBUG or lower, which causes, during that same initial call to logger.info, an internal call to logger.debug(...) (at top of multiprocessing.Queue._start_thread), all of which causes the same thread to attempt to re-acquire an already held lock.

Workaround: Set logging level to INFO or higher (something above DEBUG) to prevent the logging.debug() statement at the top of Queue._start_thread from attempting to init/lock while init is already in progress.

The following example exhibits the issue when SHOW_THE_DEADLOCK==True. Set SHOW_THE_DEADLOCK==False to observe the workaround.

from concurrent.futures import ProcessPoolExecutor
import logging
import logging.handlers
from multiprocessing import freeze_support
import multiprocessing
import sys

SHOW_THE_DEADLOCK = True # True to show the bug, False to show workaround.

g_queue: multiprocessing.Queue = None
def global_init(logging_queue):
    global g_queue
    g_queue = logging_queue

def subprocess_logging_test():
    queue_handler = logging.handlers.QueueHandler(g_queue)
    l2 = multiprocessing.get_logger()
    l2.addHandler(queue_handler)
    if not SHOW_THE_DEADLOCK:
        l2.setLevel("INFO") # default level is UNSET, if level is <= DEBUG deadlock will occur, this prevents that.
        l2.info("write to log once at info and higher to perform thread init etc.")
    l2.setLevel("DEBUG")
    l2.info("If initial level is DEBUG, deadlock here, else OK.")
    l2.warning("If initial level is DEBUG, never reach this point, else OK.")
    l2.debug("If initial level is DEBUG, never reach this point, else OK.")
    l2.info("If initial level is DEBUG, never reach this point, else OK.")

def main():
    global g_queue
    g_queue = multiprocessing.Queue(maxsize=99)
    handler = logging.StreamHandler(stream=sys.stdout)
    listener = logging.handlers.QueueListener(g_queue, handler)
    listener.start()
    with ProcessPoolExecutor(
            initializer=global_init,
            initargs=(g_queue,)
    ) as pexec:
        f = pexec.submit(subprocess_logging_test)
        f.result()
    listener.stop()

if __name__ == '__main__':
    freeze_support()
    main()

The following is an annotated stack from the above example when SHOW_THE_DEADLOCK==True.

put (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\multiprocessing\queues.py:92)
    with self._notempty:          # <----- dead lock
        if self._thread is None:
            self._start_thread()
        self._buffer.append(obj)
        self._notempty.notify()
put_nowait (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\multiprocessing\queues.py:138)
enqueue (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\handlers.py:1423)
emit (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\handlers.py:1461)
handle (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\__init__.py:968)
callHandlers (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\__init__.py:1696)
handle (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\__init__.py:1634)
_log (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\__init__.py:1624)
log (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\__init__.py:1547)
debug (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\multiprocessing\util.py:50)
_start_thread (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\multiprocessing\queues.py:165)
    def _start_thread(self):
        debug('Queue._start_thread()') # <----- at level DEBUG or lower, triggers logging call leading to deadlock.
put (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\multiprocessing\queues.py:94)
put_nowait (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\multiprocessing\queues.py:138)
enqueue (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\handlers.py:1423)
emit (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\handlers.py:1461)
handle (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\__init__.py:968)
callHandlers (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\__init__.py:1696)
handle (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\__init__.py:1634)
_log (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\__init__.py:1624)
info (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\logging\__init__.py:1477)
subprocess_logging_test (c:\PythonTesting\logging_testing.py:25)
_process_worker (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\concurrent\futures\process.py:243)
run (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\multiprocessing\process.py:108)
_bootstrap (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\multiprocessing\process.py:315)
_main (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\multiprocessing\spawn.py:129)
spawn_main (c:\Users\HappyPythonDev\AppData\Local\Programs\Python\Python310\Lib\multiprocessing\spawn.py:116)
 (:1)

Linked PRs

Activity

akulakov

akulakov commented on Apr 22, 2022

@akulakov
Contributor

I reproduced in 3.11 latest version on MacOS, both the lockup and success when setting higher debug level.

iamdbychkov

iamdbychkov commented on May 22, 2022

@iamdbychkov

see also:
#90321

duaneg

duaneg commented on Mar 27, 2025

@duaneg
Contributor
minimal-mpq-repro.py
import logging.handlers
import multiprocessing

queue = multiprocessing.Queue()
handler = logging.handlers.QueueHandler(queue)
logger = multiprocessing.get_logger()
logger.addHandler(handler)
logger.setLevel("DEBUG")
logger.debug("deadlock")

Queue's have a _notempty condition variable, created with a non-recursive lock. In this deadlock the queue handler tries to start a thread the first time a message is enqueued, however that logs a debug message to the same logger, which does the same thing again, trying to acquire the same lock and deadlocking:

Traceback (most recent call first):
  ...
This line is deadlocked trying to acquire the _notempty lock:
  File "/home/duaneg/src/cpython/Lib/multiprocessing/queues.py", line 90, in put
    with self._notempty:
  ...
  File "/home/duaneg/src/cpython/Lib/multiprocessing/util.py", line 50, in debug
    _logger.log(DEBUG, msg, *args, stacklevel=2)
  File "/home/duaneg/src/cpython/Lib/multiprocessing/queues.py", line 174, in _start_thread
    debug('Queue._start_thread()')
  ...
Note this line is called holding the _notempty lock:
  File "/home/duaneg/src/cpython/Lib/multiprocessing/queues.py", line 92, in put
    self._start_thread()
  ...
  File "/home/duaneg/src/cpython/Lib/logging/__init__.py", line 1736, in callHandlers
    hdlr.handle(record)
  ...
  File "/home/duaneg/src/cpython/Lib/logging/__init__.py", line 1507, in debug
    self._log(DEBUG, msg, args, **kwargs)
  ...

We could make the lock recursive, however that will just turn the deadlock into a stack overflow. At present, while a handler is processing a log record for a logger, it must not log anything to that same logger.

Arguably this is fair enough: that seems like an inherently bad idea, and perhaps this issue (and #90321) should just be closed as a user error. In fact there is a warning about exactly these sort of possible deadlocks in the logging.Handler documentation. However, this is a nasty latent bug for anyone unlucky enough to hit it, and it might be difficult for e.g. custom handlers calling into third-party code to be sure it will never log.

As an alternative, we could relatively easily eliminate this whole class of bug by temporarily disabling logging for a given logger while its handlers are being called. I'll push a PR for consideration shortly.

Either way, I don't think this is a multiprocessing bug per se.

added a commit that references this issue on Mar 27, 2025

pythongh-91555: disable logger while handling log record

vsajip

vsajip commented on Mar 27, 2025

@vsajip
Member

Either way, I don't think this is a multiprocessing bug per se

What value does that internal DEBUG logging in multiprocessing really have? What happens if you remove it - do this issue and #90321 both go away?

duaneg

duaneg commented on Mar 28, 2025

@duaneg
Contributor
No description provided.
vsajip

vsajip commented on Mar 28, 2025

@vsajip
Member

In this case, since multiprocessing and logging are all within the standard library and somewhat integrated already

Well, multiprocessing introduces a custom logging level, which is allowed by logging for very specific scenarios but not recommended in general, so it's not as cohesive a design as one might think.

e.g. see the Sentry logging integration code

I only had a quick look, but it seems to just sidestep their own internal logging because it would cause recursion errors.

If folks think removing the logging from multiprocessing.Queue (or even multiprocessing entirely)

I would suggest opening a discuss.python.org topic to solicit feedback from other core developers. Personally, I would consider that removing the logging from multiprocessing.Queue is reasonable (but not, for now, changing anything that doesn't need to change to address the two issues). In general, an application or library should work exactly the same independently of logging verbosity settings, which in this case multiprocessing doesn't do, ISTM.

added
type-bugAn unexpected behavior, bug, or error
stdlibPython modules in the Lib dir
on Mar 28, 2025
duaneg

duaneg commented on Mar 29, 2025

@duaneg
Contributor

I would suggest opening a discuss.python.org topic to solicit feedback from other core developers.

OK, will do, thanks!

Personally, I would consider that removing the logging from multiprocessing.Queue is reasonable (but not, for now, changing anything that doesn't need to change to address the two issues).

As it happens I was looking at a different bug in multiprocessing yesterday, and with this fresh in my mind used the built-in logging: it was very useful. It is also a publicly documented part of the module's API. Removing it doesn't feel appropriate to me, but let's see what other people think.

69 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    Status

    Done

    Status

    Done

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      multiprocessing.get_logger() logger deadlock on first call by subprocess to logger.info("...") due to internal logger.debug(...) call by multiprocessing.Queue._start_thread · Issue #91555 · python/cpython

      Follow Lee on X/Twitter - Father, Husband, Serial builder creating AI, crypto, games & web tools. We are friends :) AI Will Come To Life!

      Check out: eBank.nz (Art Generator) | Netwrck.com (AI Tools) | Text-Generator.io (AI API) | BitBank.nz (Crypto AI) | ReadingTime (Kids Reading) | RewordGame | BigMultiplayerChess | WebFiddle | How.nz | Helix AI Assistant