[issue36395] Add deferred single-threaded/fake executor to concurrent.futures
Leonardo Santagada added the comment: I have a single example: Profiling. As most python profilers don't support threads or processes, it would be very convenient to have a in process executor in those cases. -- nosy: +santagada ___ Python tracker <https://bugs.python.org/issue36395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19809] Doc: subprocess should warn uses on race conditions when multiple threads spawn child processes
Leonardo Santagada added the comment: This is still the case on windows as the pipes created to talk to the process might be inherited by two or more simultaneous CreateProcess calls. I've found a suggested solution to this: https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873 By only inheriting the stdout/err/in handles and them supporting close_fds for windows. Would more users be interested in a proper patch for this? For us now we have a lock around Popen.__init__ but that obviously doesn't suport subinterpreters and other calls to CreateProcess that might happen. -- nosy: +santagada versions: +Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue19809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26110] Speedup method calls 1.2x
Changes by Leonardo Santagada <santag...@gmail.com>: -- nosy: +santagada ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9670] Exceed Recursion Limit in Thread
Leonardo Santagada santag...@gmail.com added the comment: Why not make it bigger so it doesn't crash for much bigger functions? -- nosy: +santagada ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9670 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9670] Exceed Recursion Limit in Thread
Leonardo Santagada santag...@gmail.com added the comment: The default stack size in osx is 8MB. I think it is a safer bet, and no one is supposed to be using more than like 40-50 threads anyway (specially in 32 bit only systems limited to 8 cores). Is there a user case for hundreds/thousands of threads in python? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9670 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6763] Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)
Leonardo Santagada santag...@gmail.com added the comment: I'm on os x 10.6 where threadboom.py doesn't segfault anymore at least on the system provided python. The problem that I see is that it shouldn't be segfaulting on mac os x 10.5 with the default recursion limit (I think it is 1000) with 2 threads. IIRC in a simple recursive function (not on object __init__ like you did) I could put 1 or more as a recursion limit and still get a traceback, so I thought that 2 threads each with 1000 recursion limit should not be using the whole stack. Also I think I did try to raise the stack limit with ulimit, but I could be wrong. Nick Coghlan, did you do your experments on os x 10.5? Can you try threadboom.py on a python before the corrected mimetype lib landed (somewhere between 2.6.2 and 2.6.3) or with an old version of the mimetype lib? I got the same errors both on my old white macbook core duo machine and with a macbook pro core 2 duo and with both python 2.6.2 or 2.6.3 with the old mimetypes lib. I was worried with this bug because I guessed that maybe there is a race condition of some sort on object creation on python 2.6. If someone can reproduce the bug and understand the bug tell me it is a problem of stack size I would rest my case and be happy with the segfault :). ps: I will try to compile python2.6.2 here and reproduce the errors, if I can I will reply with more info. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6763 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6763] Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)
New submission from Leonardo Santagada santag...@gmail.com: Python 2.6.2 (and the maint branch if using old mimetypes.py) crash (with a bus error) on mac os x (10.5.7 10.5.8) with the file I posted. The problem appears to be in the allocation of memory by the GC. What I do is I call mimetypes.guess_type in more than one thread at the same time, then I guess what is happening is this: 1. The first thread to run notices mimetypes.inited is false so it call its init funtion. 2. Somehow the first thread loses the gil while still executing the init 3. Another thread tries to execute guess_type as it is already inited it calls itself, in vain as the init still hasn't exchanged it value for the new function so it goes into recursion 4. Somehow the allocator fails during the recursion here is the final pieces of my stack trace (its a very long sequence of recursions into guess_type): Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0xbffc [Switching to process 61544 thread 0x117] 0x96912122 in szone_malloc () #0 0x96912122 in szone_malloc () #1 0x969120d8 in malloc_zone_malloc () #2 0x9691206c in malloc () #3 0x0006f32c in PyObject_Malloc (nbytes=376) at Objects/obmalloc.c:913 913 return (void *)malloc(nbytes); #4 0x0006fe61 in _PyObject_DebugMalloc (nbytes=360) at Objects/obmalloc.c:1347 1347p = (uchar *)PyObject_Malloc(total); #5 0x00149b13 in _PyObject_GC_Malloc (basicsize=344) at Modules/gcmodule.c:1351 1351g = (PyGC_Head *)PyObject_MALLOC( #6 0x00149c24 in _PyObject_GC_NewVar (tp=0x193500, nitems=5) at Modules/gcmodule.c:1383 1383PyVarObject *op = (PyVarObject *) _PyObject_GC_Malloc(size); #7 0x00048a06 in PyFrame_New (tstate=0x33df30, code=0x473148, globals=0x48e380, locals=0x0) at Objects/frameobject.c:642 642 f = PyObject_GC_NewVar(PyFrameObject, PyFrame_Type, #8 0x00100816 in PyEval_EvalCodeEx (co=0x473148, globals=0x48e380, locals=0x0, args=0x374fb4, argcount=2, kws=0x374fbc, kwcount=0, defs=0x4a6f9c, defcount=1, closure=0x0) at Python/ceval.c:2755 2755f = PyFrame_New(tstate, co, globals, locals); -- components: Interpreter Core messages: 91876 nosy: santagada severity: normal status: open title: Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc) type: crash versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6763 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6763] Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)
Leonardo Santagada santag...@gmail.com added the comment: Well, the mimetypes module from 2.6 maintenance branch make this problem not show up with mimetypes.guess_type, but I still think this is a bug because pure python code should not crash the interpreter right? I'm attaching the file I mentioned, I hope this counts as a test (it needs the mimetypes module from python 2.6.2). I can probably extract just the needed functions from the old mimetypes module if requested. -- Added file: http://bugs.python.org/file14774/threadboom.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6763 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
