Mailman 3 December 2015 - pypy-dev

About gurobipy
by Luis José Novoa May 31, 2018

May 31, 2018

Hi All, My name is Luis Novoa. Im working on a large scale optimization problem using python/gurobipy for my implementation. I was wondering if any of you in this list has used gurobipy with pypy, or if it is even possible at this time. Thanks in advance, Luis.

9 9

Looking for clues to consistent Seg Fault in PyPy 2.6.1
by Jeff Doran Feb. 17, 2016

Feb. 17, 2016

Hi, I've run out of options trying to find a Seg Fault which happens when running lxml under PyPy 2.6.1. This problem only occurs under PyPy as the rest of the code works fine under CPython 2.7. I've been in contact with the lxml dev team and they confirmed my problem, but could not determine where the cause of the Seg Fault lies. They suggested reaching out to you folks for ideas or a possible work around as the stack trace is always in libpypy-c.so and seems to be triggered by eventual garbage collection. Below is the gist of the email I sent to the lxml team earlier. It describes my ability to reproduce this Seg Fault using their supplied test suite. As of this writing, lxml is at version 3.5.0b1. I'd appreciate any feedback you might supply on how to deal with this error. Seg Faults are notoriously hard to find since they inevitably happen upstream for the crash. We are anxious to perform a complete evaluation of transitioning to PyPy as our Python platform of choice and this appears to be the last major blockage. Thanks for your help. - Jeff Doran ---------------- I'm running the lxml test suite under PyPy which I installed from here,https://bitbucket.org/squeaky/portable-pypy/downloads/pypy-2.6.1-linux… . I've downloaded the current lxml src from https://github.com/lxml/lxml. I built lxml using 'python setup.py build --with-cython' *From ..lxml/src/lxml I run: * nosetests -v --pdb --nocapture Comparing with ElementTree 1.3.0 Comparing with cElementTree 1.3.0 TESTED VERSION: 3.5.0.beta1 Python: (major=2, minor=7, micro=10, releaselevel='final', serial=42) lxml.etree: (3, 5, 0, -99) libxml used: (2, 8, 0) libxml compiled: (2, 8, 0) libxslt used: (1, 1, 26) libxslt compiled: (1, 1, 26) lxml.html.tests.test_autolink.test_suite ... ok lxml.html.tests.test_basic.test_suite ... ok test_allow_tags (lxml.html.tests.test_clean.CleanerTest) ... ok test_clean_invalid_root_tag (lxml.html.tests.test_clean.CleanerTest) ... ok test_safe_attrs_excluded (lxml.html.tests.test_clean.CleanerTest) ... ok test_safe_attrs_included (lxml.html.tests.test_clean.CleanerTest) ... ok lxml.html.tests.test_clean.test_suite ... ok lxml.html.tests.test_diff.test_suite ... ok test_body (lxml.html.tests.test_elementsoup.SoupParserTestCase) ... ok test_broken_attribute (lxml.html.tests.test_elementsoup.SoupParserTestCase) ... fish: Job 1, “nosetests -v --pdb --nocapture” terminated by signal SIGSEGV (Address boundary error) ``` Running these tests under gdb reveals the following partial stack trace: #0 0x00007ffff57fa08a in ?? () from /home/jeff/debian_pypy_env/bin/libpypy-c.so #1 0x00007ffff57fa110 in ?? () from /home/jeff/debian_pypy_env/bin/libpypy-c.so #2 0x00007ffff5776be3 in PyPyWeakref_LockObject () from /home/jeff/debian_pypy_env/bin/libpypy-c.so #3 0x00007ffff0337399 in __pyx_f_4lxml_5etree__isProxyAliveInPypy.isra.265 () from /home/jeff/lxml/src/lxml/etree.pypy-26.so #4 0x00007ffff033fbfb in __pyx_f_4lxml_5etree_attemptDeallocation () from /home/jeff/lxml/src/lxml/etree.pypy-26.so #5 0x00007ffff033fd70 in __pyx_tp_dealloc_4lxml_5etree__Element () from /home/jeff/lxml/src/lxml/etree.pypy-26.so #6 0x00007ffff62186f9 in ?? () from /home/jeff/debian_pypy_env/bin/libpypy-c.so #7 0x00007ffff57aec90 in ?? () from /home/jeff/debian_pypy_env/bin/libpypy-c.so #8 0x00007ffff57fa670 in ?? () from /home/jeff/debian_pypy_env/bin/libpypy-c.so #9 0x00007ffff5fa0da8 in ?? () from /home/jeff/debian_pypy_env/bin/libpypy-c.so #10 0x00007ffff5f89a31 in ?? ()

6 17

using python-ldap under pypy
by Elmir Jagudin Jan. 20, 2016

Jan. 20, 2016

Hi I'm trying to run an application under pypy that authenticates user with LDAP. It is using python-ldap module and it fails to lookup the users. The problem is in python-ldap's c extension code. When it converts the LDAP search query from python format to C, parts of the query are corrupted. Is python-ldap supposed to work under pypy? How compatible is the python C API between cpython and pypy? Right now I can't figure out if this is a bug in python-ldap code or an compatibility with Pypy C API. Regards, Elmir Jagudin

3 7

Re: [pypy-dev] Dead loop occurs when using python-daemon and multiprocessing together in PyPy 4.0.1
by Maciej Fijalkowski Jan. 5, 2016

Jan. 5, 2016

well, ok, but that does not sound like a pypy bug then - "close all existing fds and complain that some of them are closed" is a bit not good - maybe it's a bug in python-daemon and the PEP? On Wed, Dec 23, 2015 at 3:36 PM, hubo <hubo(a)jiedaibao.com> wrote: > No, the python-daemon module is critical in this problem, because it is > the python-daemon module who closed the fd to /dev/urandom. When process > swith to daemon, it forks itself, and then close all open fds (including > stdin, stdout and stderr), so it also closes the fd for /dev/urandom which > is used by PyPy library. It is the standard behavior defined by > https://www.python.org/dev/peps/pep-3143/#daemoncontext-objects and also > the standard behavior for unix daemons. And unfortunately there is not a > way to prevent the fd to be closed without knowing exactly what number it > is on. > > Without python-daemon (or similar libraries), it is only possible to > reproduce the problem by closing the fd (usually 4) forcely, but it does > not make much sense. > > > 2015-12-23 > ------------------------------ > hubo > ------------------------------ > > *发件人：*Maciej Fijalkowski <fijall(a)gmail.com> > *发送时间：*2015-12-23 21:22 > *主题：*Re: Re: Re: [pypy-dev] Dead loop occurs when using python-daemon and > multiprocessing together in PyPy 4.0.1 > *收件人：*"hubo"<hubo(a)jiedaibao.com> > *抄送：*"pypy-dev"<pypy-dev(a)python.org> > > can you reproduce the OSError problem without having the daemon module > involved either? > > On Wed, Dec 23, 2015 at 3:14 PM, hubo <hubo(a)jiedaibao.com> wrote: > >> I can only reproduce the *OSError* problem. Maybe the CPU 100% is not >> really a dead lock, but rather some kind of automatic crash report? >> Although it is quite easy to crash the program with os.urandom, it >> only stops responding when the crash happens in system libraries like >> multiprocessing or email. >> >> The posix.urandom problem is quite easy to reproduce: >> >> #!/usr/bin/pypy >> import os >> os.urandom(16) >> def test(): >> print repr(os.urandom(16)) >> import daemon >> import sys >> if __name__ == '__main__': >> with daemon.DaemonContext(initgroups=False, >> stderr=sys.stderr,stdout=sys.stdout): >> test() >> >> (stderr and stdout is kept open to show console messages in the daemon. >> initgroups=False is a workaround on python-daemon not working in Python2.6) >> >> Or, with module random: >> >> #!/usr/bin/pypy >> import random >> def test(): >> random.Random() >> import daemon >> import sys >> if __name__ == '__main__': >> with daemon.DaemonContext(initgroups=False, >> stderr=sys.stderr,stdout=sys.stdout): >> test() >> And when run scripts with pypy: >> >> pypy test3.py >> >> it crashes with OSError: >> Traceback (most recent call last): >> File "test2.py", line 13, in <module> >> test() >> File "test2.py", line 6, in test >> random.Random() >> File "/opt/pypy-4.0.1-linux_x86_64-portable/lib-python/2.7/random.py", >> line 95, in __init__ >> self.seed(x) >> File "/opt/pypy-4.0.1-linux_x86_64-portable/lib-python/2.7/random.py", >> line 111, in seed >> a = long(_hexlify(_urandom(2500)), 16) >> OSError: [Errno 9] Bad file descriptor >> >> It is still not clear why it causes dead loop (or long-time no >> responding) in multiprocessing (should have thrown an ImportError) and the >> exact condition for the file descriptor of /dev/urandom appears (just call >> os.urandom and import random does not reproduce the result), but I believe >> it is definitely linked to the problem. >> >> 2015-12-23 >> ------------------------------ >> hubo >> ------------------------------ >> >> *发件人：*Maciej Fijalkowski <fijall(a)gmail.com> >> *发送时间：*2015-12-23 20:07 >> *主题：*Re: Re: [pypy-dev] Dead loop occurs when using python-daemon and >> multiprocessing together in PyPy 4.0.1 >> *收件人：*"hubo"<hubo(a)jiedaibao.com> >> *抄送：*"pypy-dev"<pypy-dev(a)python.org> >> >> That's very interesting, can you produce a standalone example that does >> not use multiprocessing? That would make it much easier to fix the bug >> (e.g. os.fork followed by os.urandom failing) >> >> On Wed, Dec 23, 2015 at 1:54 PM, hubo <hubo(a)jiedaibao.com> wrote: >> >>> Thanks for the response. Should I put it directly in the bug tracker? >>> >>> FYI, I've located the reason to be the incompatibility with >>> python-daemon (or rather the standard unix-daemon behavior) and PyPy >>> *posix.urandom* implementation. >>> >>> It seems that in PyPy 4.0.1, when module *random* loaded, a file >>> descriptor is created on /dev/urandom. I think PyPy implementation use the >>> shared descriptor to read from /dev/urandom. Sadly when python-daemon fork >>> the process and turns it into an unix daemon, it closes all the currently >>> open file descriptors. After that all os.urandom calls failed with OSError. >>> I think maybe the other functions of Random class is also using the file >>> descriptor in C code and just never detects if the return value is 0, and >>> causes the dead loop. >>> >>> I think the problem will be solved if the implementation re-open the >>> handle when it is closed somehow. >>> >>> multiprocessing is using random internally. Also there are lots of other >>> modules using random, like email etc. The dead loop occurs when you use any >>> of the libraries in a daemon. >>> >>> >>> >>> 2015-12-23 >>> ------------------------------ >>> hubo >>> ------------------------------ >>> >>> *发件人：*Maciej Fijalkowski <fijall(a)gmail.com> >>> *发送时间：*2015-12-23 19:35 >>> *主题：*Re: [pypy-dev] Dead loop occurs when using python-daemon and >>> multiprocessing together in PyPy 4.0.1 >>> *收件人：*"hubo"<hubo(a)jiedaibao.com> >>> *抄送：*"pypy-dev"<pypy-dev(a)python.org> >>> >>> Hi hubo >>> >>> Can you put it as a bug report? Those things get easily lost on the >>> mailing list (and sadly I won't look at it right now, multiprocessing >>> scares me) >>> >>> On Wed, Dec 23, 2015 at 12:03 PM, hubo <hubo(a)jiedaibao.com> wrote: >>> >>>> Hello devs, >>>> >>>> A (possible) dead loop is found when I use python-daemon and >>>> multiprocessing together in PyPy 4.0.1, which does not appear in Python(2.6 >>>> or 2.7). Also it does not appear in earlier PyPy versions (2.0.2) >>>> >>>> *Reproduce*: >>>> >>>> First install python-daemon: >>>> pypy_pip install python-daemon >>>> >>>> Use the following test script (also available in attachment): >>>> >>>> #!/usr/bin/pypy >>>> import daemon >>>> import multiprocessing >>>> def test(): >>>> q = multiprocessing.Queue(64) >>>> if __name__ == '__main__': >>>> with daemon.DaemonContext(): >>>> test() >>>> >>>> When executing the script with pypy: >>>> pypy test.py >>>> >>>> The background service does not exit, and is consuming 100% CPU: >>>> ps aux | grep pypy >>>> root 7769 99.1 0.5 235332 46812 ? R 17:52 2:09 pypy >>>> test.py >>>> root 7775 0.0 0.0 103252 804 pts/1 S+ 17:54 0:00 grep >>>> pypy >>>> >>>> >>>> >>>> Executing the script with python: >>>> python2.7 test.py >>>> And the background service normally exits. >>>> >>>> *Environment:* >>>> I'm using CentOS 6.5, with portable PyPy distribution for linux ( >>>> https://bitbucket.org/squeaky/portable-pypy/downloads/pypy-4.0.1-linux_x86_… >>>> ) >>>> I run the script on system built-in python (python 2.6.6), a compiled >>>> CPython (2.7.11), and pypy from epel-release(pypy 2.0.2, python 2.7.2), and >>>> the problem does not appear. Though the compiled CPython is 2.7.11 and PyPy >>>> 4.0.4 is python 2.7.10, I think that does not matter much. >>>> >>>> Please contact if you have any questions or ideas. >>>> >>>> >>>> 2015-12-23 >>>> ------------------------------ >>>> hubo >>>> >>>> _______________________________________________ >>>> pypy-dev mailing list >>>> pypy-dev(a)python.org >>>> https://mail.python.org/mailman/listinfo/pypy-dev >>>> >>>> >>> >> >

5 15

Leysin Winter sprint?
by Armin Rigo Jan. 1, 2016

Jan. 1, 2016

Hi all, Due to public pressure :-) I'm trying to organize this winter's sprint, in Leysin, Switzerland. This is a fully public sprint of 7 days, with possible skiing. If you'd like to come, please reply to this e-mail with dates that are ok for you. I will give some priority to core people, but anyone else is welcome to have preferences too. Traditionally, it is around mid-January, but this year as far as I understand there is some push to have it in February or March instead---which is fine too. The following week should be avoided if possible, as it is holidays for the canton's schools: 20-28 Feb 2016. A bientôt, Armin.

7 11

Current status of GUI support in PyPy
by Oscar Benjamin Dec. 31, 2015

Dec. 31, 2015

After a casual bit of googling I'm not sure what is the current status of GUI support in PyPy. Does tkinter work with PyPy yet (It doesn't in the version I have installed here)? Is there any other GUI that you recommend? I'm looking to make a Python-based physics simulator that should be able to show animations in some kind of GUI. I would like to have some kind of web-based format as one output of this (so that results can be shown on the web) but I'm not sure how good that would be for interactive simulation. The physics calculations require that I need to use either PyPy or Cython or something (not plain CPython) to get reasonable performance. One possibility is that I could run PyPy in a subprocess from a CPython-based GUI which I guess is not dissimilar to getting it to work in the browser except I get to write the front-end in Python. -- Oscar

5 15

Re: [pypy-dev] Dead loop occurs when using python-daemon and multiprocessing together in PyPy 4.0.1
by Maciej Fijalkowski Dec. 23, 2015

Dec. 23, 2015

can you reproduce the OSError problem without having the daemon module involved either? On Wed, Dec 23, 2015 at 3:14 PM, hubo <hubo(a)jiedaibao.com> wrote: > I can only reproduce the *OSError* problem. Maybe the CPU 100% is not > really a dead lock, but rather some kind of automatic crash report? > Although it is quite easy to crash the program with os.urandom, it > only stops responding when the crash happens in system libraries like > multiprocessing or email. > > The posix.urandom problem is quite easy to reproduce: > > #!/usr/bin/pypy > import os > os.urandom(16) > def test(): > print repr(os.urandom(16)) > import daemon > import sys > if __name__ == '__main__': > with daemon.DaemonContext(initgroups=False, > stderr=sys.stderr,stdout=sys.stdout): > test() > > (stderr and stdout is kept open to show console messages in the daemon. > initgroups=False is a workaround on python-daemon not working in Python2.6) > > Or, with module random: > > #!/usr/bin/pypy > import random > def test(): > random.Random() > import daemon > import sys > if __name__ == '__main__': > with daemon.DaemonContext(initgroups=False, > stderr=sys.stderr,stdout=sys.stdout): > test() > And when run scripts with pypy: > > pypy test3.py > > it crashes with OSError: > Traceback (most recent call last): > File "test2.py", line 13, in <module> > test() > File "test2.py", line 6, in test > random.Random() > File "/opt/pypy-4.0.1-linux_x86_64-portable/lib-python/2.7/random.py", > line 95, in __init__ > self.seed(x) > File "/opt/pypy-4.0.1-linux_x86_64-portable/lib-python/2.7/random.py", > line 111, in seed > a = long(_hexlify(_urandom(2500)), 16) > OSError: [Errno 9] Bad file descriptor > > It is still not clear why it causes dead loop (or long-time no responding) > in multiprocessing (should have thrown an ImportError) and the exact > condition for the file descriptor of /dev/urandom appears (just call > os.urandom and import random does not reproduce the result), but I believe > it is definitely linked to the problem. > > 2015-12-23 > ------------------------------ > hubo > ------------------------------ > > *发件人：*Maciej Fijalkowski <fijall(a)gmail.com> > *发送时间：*2015-12-23 20:07 > *主题：*Re: Re: [pypy-dev] Dead loop occurs when using python-daemon and > multiprocessing together in PyPy 4.0.1 > *收件人：*"hubo"<hubo(a)jiedaibao.com> > *抄送：*"pypy-dev"<pypy-dev(a)python.org> > > That's very interesting, can you produce a standalone example that does > not use multiprocessing? That would make it much easier to fix the bug > (e.g. os.fork followed by os.urandom failing) > > On Wed, Dec 23, 2015 at 1:54 PM, hubo <hubo(a)jiedaibao.com> wrote: > >> Thanks for the response. Should I put it directly in the bug tracker? >> >> FYI, I've located the reason to be the incompatibility with python-daemon >> (or rather the standard unix-daemon behavior) and PyPy *posix.urandom* >> implementation. >> >> It seems that in PyPy 4.0.1, when module *random* loaded, a file >> descriptor is created on /dev/urandom. I think PyPy implementation use the >> shared descriptor to read from /dev/urandom. Sadly when python-daemon fork >> the process and turns it into an unix daemon, it closes all the currently >> open file descriptors. After that all os.urandom calls failed with OSError. >> I think maybe the other functions of Random class is also using the file >> descriptor in C code and just never detects if the return value is 0, and >> causes the dead loop. >> >> I think the problem will be solved if the implementation re-open the >> handle when it is closed somehow. >> >> multiprocessing is using random internally. Also there are lots of other >> modules using random, like email etc. The dead loop occurs when you use any >> of the libraries in a daemon. >> >> >> >> 2015-12-23 >> ------------------------------ >> hubo >> ------------------------------ >> >> *发件人：*Maciej Fijalkowski <fijall(a)gmail.com> >> *发送时间：*2015-12-23 19:35 >> *主题：*Re: [pypy-dev] Dead loop occurs when using python-daemon and >> multiprocessing together in PyPy 4.0.1 >> *收件人：*"hubo"<hubo(a)jiedaibao.com> >> *抄送：*"pypy-dev"<pypy-dev(a)python.org> >> >> Hi hubo >> >> Can you put it as a bug report? Those things get easily lost on the >> mailing list (and sadly I won't look at it right now, multiprocessing >> scares me) >> >> On Wed, Dec 23, 2015 at 12:03 PM, hubo <hubo(a)jiedaibao.com> wrote: >> >>> Hello devs, >>> >>> A (possible) dead loop is found when I use python-daemon and >>> multiprocessing together in PyPy 4.0.1, which does not appear in Python(2.6 >>> or 2.7). Also it does not appear in earlier PyPy versions (2.0.2) >>> >>> *Reproduce*: >>> >>> First install python-daemon: >>> pypy_pip install python-daemon >>> >>> Use the following test script (also available in attachment): >>> >>> #!/usr/bin/pypy >>> import daemon >>> import multiprocessing >>> def test(): >>> q = multiprocessing.Queue(64) >>> if __name__ == '__main__': >>> with daemon.DaemonContext(): >>> test() >>> >>> When executing the script with pypy: >>> pypy test.py >>> >>> The background service does not exit, and is consuming 100% CPU: >>> ps aux | grep pypy >>> root 7769 99.1 0.5 235332 46812 ? R 17:52 2:09 pypy >>> test.py >>> root 7775 0.0 0.0 103252 804 pts/1 S+ 17:54 0:00 grep >>> pypy >>> >>> >>> >>> Executing the script with python: >>> python2.7 test.py >>> And the background service normally exits. >>> >>> *Environment:* >>> I'm using CentOS 6.5, with portable PyPy distribution for linux ( >>> https://bitbucket.org/squeaky/portable-pypy/downloads/pypy-4.0.1-linux_x86_… >>> ) >>> I run the script on system built-in python (python 2.6.6), a compiled >>> CPython (2.7.11), and pypy from epel-release(pypy 2.0.2, python 2.7.2), and >>> the problem does not appear. Though the compiled CPython is 2.7.11 and PyPy >>> 4.0.4 is python 2.7.10, I think that does not matter much. >>> >>> Please contact if you have any questions or ideas. >>> >>> >>> 2015-12-23 >>> ------------------------------ >>> hubo >>> >>> _______________________________________________ >>> pypy-dev mailing list >>> pypy-dev(a)python.org >>> https://mail.python.org/mailman/listinfo/pypy-dev >>> >>> >> >

2 1

Re: [pypy-dev] Dead loop occurs when using python-daemon and multiprocessing together in PyPy 4.0.1
by Maciej Fijalkowski Dec. 23, 2015

Dec. 23, 2015

That's very interesting, can you produce a standalone example that does not use multiprocessing? That would make it much easier to fix the bug (e.g. os.fork followed by os.urandom failing) On Wed, Dec 23, 2015 at 1:54 PM, hubo <hubo(a)jiedaibao.com> wrote: > Thanks for the response. Should I put it directly in the bug tracker? > > FYI, I've located the reason to be the incompatibility with python-daemon > (or rather the standard unix-daemon behavior) and PyPy *posix.urandom* > implementation. > > It seems that in PyPy 4.0.1, when module *random* loaded, a file > descriptor is created on /dev/urandom. I think PyPy implementation use the > shared descriptor to read from /dev/urandom. Sadly when python-daemon fork > the process and turns it into an unix daemon, it closes all the currently > open file descriptors. After that all os.urandom calls failed with OSError. > I think maybe the other functions of Random class is also using the file > descriptor in C code and just never detects if the return value is 0, and > causes the dead loop. > > I think the problem will be solved if the implementation re-open the > handle when it is closed somehow. > > multiprocessing is using random internally. Also there are lots of other > modules using random, like email etc. The dead loop occurs when you use any > of the libraries in a daemon. > > > > 2015-12-23 > ------------------------------ > hubo > ------------------------------ > > *发件人：*Maciej Fijalkowski <fijall(a)gmail.com> > *发送时间：*2015-12-23 19:35 > *主题：*Re: [pypy-dev] Dead loop occurs when using python-daemon and > multiprocessing together in PyPy 4.0.1 > *收件人：*"hubo"<hubo(a)jiedaibao.com> > *抄送：*"pypy-dev"<pypy-dev(a)python.org> > > Hi hubo > > Can you put it as a bug report? Those things get easily lost on the > mailing list (and sadly I won't look at it right now, multiprocessing > scares me) > > On Wed, Dec 23, 2015 at 12:03 PM, hubo <hubo(a)jiedaibao.com> wrote: > >> Hello devs, >> >> A (possible) dead loop is found when I use python-daemon and >> multiprocessing together in PyPy 4.0.1, which does not appear in Python(2.6 >> or 2.7). Also it does not appear in earlier PyPy versions (2.0.2) >> >> *Reproduce*: >> >> First install python-daemon: >> pypy_pip install python-daemon >> >> Use the following test script (also available in attachment): >> >> #!/usr/bin/pypy >> import daemon >> import multiprocessing >> def test(): >> q = multiprocessing.Queue(64) >> if __name__ == '__main__': >> with daemon.DaemonContext(): >> test() >> >> When executing the script with pypy: >> pypy test.py >> >> The background service does not exit, and is consuming 100% CPU: >> ps aux | grep pypy >> root 7769 99.1 0.5 235332 46812 ? R 17:52 2:09 pypy >> test.py >> root 7775 0.0 0.0 103252 804 pts/1 S+ 17:54 0:00 grep pypy >> >> >> >> Executing the script with python: >> python2.7 test.py >> And the background service normally exits. >> >> *Environment:* >> I'm using CentOS 6.5, with portable PyPy distribution for linux ( >> https://bitbucket.org/squeaky/portable-pypy/downloads/pypy-4.0.1-linux_x86_… >> ) >> I run the script on system built-in python (python 2.6.6), a compiled >> CPython (2.7.11), and pypy from epel-release(pypy 2.0.2, python 2.7.2), and >> the problem does not appear. Though the compiled CPython is 2.7.11 and PyPy >> 4.0.4 is python 2.7.10, I think that does not matter much. >> >> Please contact if you have any questions or ideas. >> >> >> 2015-12-23 >> ------------------------------ >> hubo >> >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev(a)python.org >> https://mail.python.org/mailman/listinfo/pypy-dev >> >> >

2 1

Re: [pypy-dev] Dead loop occurs when using python-daemon and multiprocessing together in PyPy 4.0.1
by Maciej Fijalkowski Dec. 23, 2015

Dec. 23, 2015

Hi hubo Can you put it as a bug report? Those things get easily lost on the mailing list (and sadly I won't look at it right now, multiprocessing scares me) On Wed, Dec 23, 2015 at 12:03 PM, hubo <hubo(a)jiedaibao.com> wrote: > Hello devs, > > A (possible) dead loop is found when I use python-daemon and > multiprocessing together in PyPy 4.0.1, which does not appear in Python(2.6 > or 2.7). Also it does not appear in earlier PyPy versions (2.0.2) > > *Reproduce*: > > First install python-daemon: > pypy_pip install python-daemon > > Use the following test script (also available in attachment): > > #!/usr/bin/pypy > import daemon > import multiprocessing > def test(): > q = multiprocessing.Queue(64) > if __name__ == '__main__': > with daemon.DaemonContext(): > test() > > When executing the script with pypy: > pypy test.py > > The background service does not exit, and is consuming 100% CPU: > ps aux | grep pypy > root 7769 99.1 0.5 235332 46812 ? R 17:52 2:09 pypy > test.py > root 7775 0.0 0.0 103252 804 pts/1 S+ 17:54 0:00 grep pypy > > > > Executing the script with python: > python2.7 test.py > And the background service normally exits. > > *Environment:* > I'm using CentOS 6.5, with portable PyPy distribution for linux ( > https://bitbucket.org/squeaky/portable-pypy/downloads/pypy-4.0.1-linux_x86_… > ) > I run the script on system built-in python (python 2.6.6), a compiled > CPython (2.7.11), and pypy from epel-release(pypy 2.0.2, python 2.7.2), and > the problem does not appear. Though the compiled CPython is 2.7.11 and PyPy > 4.0.4 is python 2.7.10, I think that does not matter much. > > Please contact if you have any questions or ideas. > > > 2015-12-23 > ------------------------------ > hubo > > _______________________________________________ > pypy-dev mailing list > pypy-dev(a)python.org > https://mail.python.org/mailman/listinfo/pypy-dev > >

2 1

Dead loop occurs when using python-daemon and multiprocessing together in PyPy 4.0.1
by hubo Dec. 23, 2015

Dec. 23, 2015

Hello devs, A (possible) dead loop is found when I use python-daemon and multiprocessing together in PyPy 4.0.1, which does not appear in Python(2.6 or 2.7). Also it does not appear in earlier PyPy versions (2.0.2) Reproduce: First install python-daemon: pypy_pip install python-daemon Use the following test script (also available in attachment): #!/usr/bin/pypy import daemon import multiprocessing def test(): q = multiprocessing.Queue(64) if __name__ == '__main__': with daemon.DaemonContext(): test() When executing the script with pypy: pypy test.py The background service does not exit, and is consuming 100% CPU: ps aux | grep pypy root 7769 99.1 0.5 235332 46812 ? R 17:52 2:09 pypy test.py root 7775 0.0 0.0 103252 804 pts/1 S+ 17:54 0:00 grep pypy Executing the script with python: python2.7 test.py And the background service normally exits. Environment: I'm using CentOS 6.5, with portable PyPy distribution for linux (https://bitbucket.org/squeaky/portable-pypy/downloads/pypy-4.0.1-linux_x86_…) I run the script on system built-in python (python 2.6.6), a compiled CPython (2.7.11), and pypy from epel-release(pypy 2.0.2, python 2.7.2), and the problem does not appear. Though the compiled CPython is 2.7.11 and PyPy 4.0.4 is python 2.7.10, I think that does not matter much. Please contact if you have any questions or ideas. 2015-12-23 hubo

1 0