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: segfault caused by nested calls to map()
Type: crash Stage: resolved
Components: Versions: Python 3.4
process
Status: closed Resolution: duplicate
Dependencies: Superseder: deeply nested itertools objects segfault
View: 14010
Assigned To: Nosy List: BreamoreBoy, dlukes, serhiy.storchaka
Priority: normal Keywords:

Created on 2015-07-10 15:50 by dlukes, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (4)
msg246567 - (view) Author: David Lukeš (dlukes) * Date: 2015-07-10 15:50
The following program makes Python 3.4.3 crash with a segmentation fault:

```
#!/usr/bin/env python3

import operator

N = 500000
l = [0]

for i in range(N):
    l = map(operator.add, l, [1])

print(list(l))
```

I suppose the problem is that there are too many nested lazy calls to map, which cause a segfault when evaluated. I've played with N and surprisingly, the threshold to cause the crash varied slightly (between 130900 and 131000 on my machine).

I know that a list-comprehension, which is evaluated straight away, would be much more idiomatic for repeated element-wise addition (or numpy arrays for that matter, if available). I'm **not advocating this piece of code**, just wondering whether there couldn't be a more informative way to make Python bail out instead of the segfault? (In my real application, it took me a while to figure where the problem was without a stack trace.)
msg246588 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2015-07-11 00:32
FTR I can reproduce this on Windows 8.1 with 3.4.3 and 3.3.5 but not 2.7.10 or 2.6.6.
msg246591 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2015-07-11 02:54
Process 51270 launched: './python' (x86_64)
Process 51270 stopped
* thread #1: tid = 0x5c8677, 0x00000001000c1af8 python`_PyObject_Alloc(use_calloc=0, ctx=<unavailable>, nelem=<unavailable>, elsize=<unavailable>) + 24 at obmalloc.c:1170, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5ebffff8)
    frame #0: 0x00000001000c1af8 python`_PyObject_Alloc(use_calloc=0, ctx=<unavailable>, nelem=<unavailable>, elsize=<unavailable>) + 24 at obmalloc.c:1170
   1167
   1168	static void *
   1169	_PyObject_Alloc(int use_calloc, void *ctx, size_t nelem, size_t elsize)
-> 1170	{
   1171	    size_t nbytes;
   1172	    block *bp;
   1173	    poolp pool;
(lldb) bt
* thread #1: tid = 0x5c8677, 0x00000001000c1af8 python`_PyObject_Alloc(use_calloc=0, ctx=<unavailable>, nelem=<unavailable>, elsize=<unavailable>) + 24 at obmalloc.c:1170, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5ebffff8)
  * frame #0: 0x00000001000c1af8 python`_PyObject_Alloc(use_calloc=0, ctx=<unavailable>, nelem=<unavailable>, elsize=<unavailable>) + 24 at obmalloc.c:1170
    frame #1: 0x00000001000c0ec8 python`_PyObject_Malloc(ctx=0x0000000000000000, nbytes=112) + 40 at obmalloc.c:1386
    frame #2: 0x00000001000c03e9 python`_PyMem_DebugAlloc(use_calloc=0, ctx=0x0000000100390898, nbytes=80) + 153 at obmalloc.c:1838
    frame #3: 0x00000001000be981 python`_PyMem_DebugMalloc(ctx=0x0000000100390898, nbytes=80) + 33 at obmalloc.c:1861
    frame #4: 0x00000001000bf3c1 python`PyObject_Malloc(size=80) + 65 at obmalloc.c:386
    frame #5: 0x000000010028c87e python`_PyObject_GC_Alloc(use_calloc=0, basicsize=56) + 110 at gcmodule.c:1696
    frame #6: 0x000000010028c809 python`_PyObject_GC_Malloc(basicsize=56) + 25 at gcmodule.c:1718
    frame #7: 0x000000010028ca6d python`_PyObject_GC_NewVar(tp=0x0000000100393990, nitems=2) + 109 at gcmodule.c:1747
    frame #8: 0x00000001000d6c82 python`PyTuple_New(size=2) + 338 at tupleobject.c:104
    frame #9: 0x00000001001d7e26 python`map_next(lz=0x000000010cebbae8) + 38 at bltinmodule.c:1162
    frame #10: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbae8) + 44 at abstract.c:2760
    frame #11: 0x00000001001d7e71 python`map_next(lz=0x000000010cebbbb8) + 113 at bltinmodule.c:1167
    frame #12: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbbb8) + 44 at abstract.c:2760
    frame #13: 0x00000001001d7e71 python`map_next(lz=0x000000010cebbc88) + 113 at bltinmodule.c:1167
    frame #14: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbc88) + 44 at abstract.c:2760
    frame #15: 0x00000001001d7e71 python`map_next(lz=0x000000010cebbd58) + 113 at bltinmodule.c:1167
    frame #16: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbd58) + 44 at abstract.c:2760
    frame #17: 0x00000001001d7e71 python`map_next(lz=0x000000010cebbe28) + 113 at bltinmodule.c:1167
    frame #18: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbe28) + 44 at abstract.c:2760
    frame #19: 0x00000001001d7e71 python`map_next(lz=0x000000010cebbef8) + 113 at bltinmodule.c:1167
    frame #20: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbef8) + 44 at abstract.c:2760
    frame #21: 0x00000001001d7e71 python`map_next(lz=0x000000010cebd058) + 113 at bltinmodule.c:1167
    frame #22: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebd058) + 44 at abstract.c:2760
    frame #23: 0x00000001001d7e71 python`map_next(lz=0x000000010cebd128) + 113 at bltinmodule.c:1167
    frame #24: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebd128) + 44 at abstract.c:2760
[...]
msg246593 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-07-11 04:50
This looks as a duplicate of issue14010.
History
Date User Action Args
2022-04-11 14:58:18adminsetgithub: 68794
2015-07-11 04:50:56serhiy.storchakasetstatus: open -> closed

superseder: deeply nested itertools objects segfault

nosy: + serhiy.storchaka
messages: + msg246593
resolution: duplicate
stage: resolved
2015-07-11 02:55:10ned.deilysetnosy: - ned.deily
2015-07-11 02:54:30ned.deilysetnosy: + ned.deily
messages: + msg246591
2015-07-11 00:32:08BreamoreBoysetnosy: + BreamoreBoy
messages: + msg246588
2015-07-10 15:50:22dlukescreate