On 07/03/2017 06:04 PM, Armin Rigo wrote:
Hi Pavlo,
On 3 July 2017 at 16:25, Pavlo Lavrenenko <sa...@portaone.com> wrote:
Running PyPy 5.6.0 with GCC 4.8.5 20150623 (Red Hat 4.8.5-4) here.
Occasionally PyPy terminates with signal 11 and a long stack consisting
mostly of: #31 0x00007f0d4c26ce7d in ?? () from /lib64/libpypy-c.so
I would try first upgrading to PyPy 5.8.0.
Hello Armin,
any prominent changes between 5.6.0 and 5.8.0? Can I find the change logs
somewhere?
kill -11 doesn't give the result I want. Any way to make PyPy crash
somewhere in /lib64/libpypy-c.so?
``os.kill(os.getpid(), signal.SIGSEGV)``? If that's what you tried
and it doesn't give the results you want, please explain in more
details why not.
I don't understand why myself. The software works as:
# there is master process and N children
# master periodically checks if children are alive
(multiprocessing.Process.is_alive())
# if not, master process calls join() and creates a new multiprocessing.Process
instance
This whole machinery works fine if I send 11 signal to the child but stucks
either after join() or further on the process creation. There is not enough
logging in the software to trace the issue and the issue quite rare. Moreover
when it comes to production and the issue is reproduced engineers just restart
everything manually.
A bientôt,
Armin.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
