Issue24606
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.
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) * ![]() |
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) * ![]() |
Date: 2015-07-11 04:50 | |
This looks as a duplicate of issue14010. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:58:18 | admin | set | github: 68794 |
2015-07-11 04:50:56 | serhiy.storchaka | set | status: open -> closed superseder: deeply nested itertools objects segfault nosy: + serhiy.storchaka messages: + msg246593 resolution: duplicate stage: resolved |
2015-07-11 02:55:10 | ned.deily | set | nosy:
- ned.deily |
2015-07-11 02:54:30 | ned.deily | set | nosy:
+ ned.deily messages: + msg246591 |
2015-07-11 00:32:08 | BreamoreBoy | set | nosy:
+ BreamoreBoy messages: + msg246588 |
2015-07-10 15:50:22 | dlukes | create |