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: Spurious OSError "Not enough memory resources" when allocating memory using multiprocessing.RawArray
Type: behavior Stage: resolved
Components: Library (Lib), Windows Versions: Python 3.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: bkardon, christian.heimes, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2019-11-26 21:22 by bkardon, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
memoryErrorTest.py bkardon, 2019-11-26 21:22 A minimal reproducible example of the error
Messages (4)
msg357531 - (view) Author: Brian Kardon (bkardon) Date: 2019-11-26 21:22
When I try to create a series of multiprocessing.RawArray objects, I get an "OSError: Not enough memory resources are available to process this command". However, by my calculations, the total amount of memory I'm trying to allocate is just about 1 GB, and my system reports that it has around 20 GB free memory. I can't find any information about any artificial memory limit, and my system seems to have plenty of memory for this, so it seems like a bug to me. This is my first issue report, so I apologize if I'm doing this wrong.

The attached script produces the following output on my Windows 10 64-bit machine with Python 3.7:

Creating buffer # 0
Creating buffer # 1
Creating buffer # 2
Creating buffer # 3
Creating buffer # 4
...etc...
Creating buffer # 276
Creating buffer # 277
Creating buffer # 278
Creating buffer # 279
Creating buffer # 280
Traceback (most recent call last):
  File ".\Cruft\memoryErrorTest.py", line 10, in <module>
    buffers.append(mp.RawArray(imageDataType, imageDataSize))
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\context.py", line 129, in RawArray
    return RawArray(typecode_or_type, size_or_initializer)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\sharedctypes.py", line 61, in RawArray
    obj = _new_value(type_)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\sharedctypes.py", line 41, in _new_value
    wrapper = heap.BufferWrapper(size)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 263, in __init__
    block = BufferWrapper._heap.malloc(size)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 242, in malloc
    (arena, start, stop) = self._malloc(size)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 134, in _malloc
    arena = Arena(length)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 38, in __init__
    buf = mmap.mmap(-1, size, tagname=name)
OSError: [WinError 8] Not enough memory resources are available to process this command
msg357532 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2019-11-26 21:52
You appear to be using a 32-bit version of Python on Windows; do you get the same behavior using the 64-bit version?
msg357533 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2019-11-26 22:17
Good catch, Zach! A 32bit version of Python would certainly explain your problem. A 32bit process can only address 4 GB of address space. Almost half of the address space is reserved for OS, stack, Python itself, and other things. That leaves a little more than 2 GB of free heap memory for user data. Due to memory fragmentation it is possible that the allocator can't find a continuous free block 1 GB.
msg357541 - (view) Author: Brian Kardon (bkardon) Date: 2019-11-27 00:21
Ah, thank you so much! That makes sense. I'll have to switch to 64-bit python. 

I've marked this as closed - hope that's the right thing to do here.
History
Date User Action Args
2022-04-11 14:59:23adminsetgithub: 83104
2019-11-27 00:21:46bkardonsetstatus: open -> closed
resolution: not a bug
messages: + msg357541

stage: resolved
2019-11-26 22:17:56christian.heimessetnosy: + christian.heimes
messages: + msg357533
2019-11-26 21:52:38zach.waresetmessages: + msg357532
components: - ctypes
2019-11-26 21:22:27bkardoncreate