On 07/04/2017 01:45 PM, Santa wrote:
On 07/03/2017 06:04 PM, Armin Rigo wrote:
I don't understand why myself. The software works as:
Anyway I wrote a CFFI module with a function that dereferences NULL and called
the function in the application. Did the trick I wanted.
--
Best regards,
Pavl
Hi,
On 4 July 2017 at 12:47, Pavlo Lavrenenko wrote:
> any prominent changes between 5.6.0 and 5.8.0? Can I find the change logs
> somewhere?
There were fixes for very rare crashes, notably in the JIT. It's not
possible to say "avoid doing this or that and it will avoid the bug".
The JIT doesn'
On 07/03/2017 06:04 PM, Armin Rigo wrote:
Hi Pavlo,
On 3 July 2017 at 16:25, Pavlo Lavrenenko 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 0x7f0d4c26ce7d in ?? () from /lib64
On 07/03/2017 06:04 PM, Armin Rigo wrote:
Hi Pavlo,
On 3 July 2017 at 16:25, Pavlo Lavrenenko 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 0x7f0d4c26ce7d in ?? () from /lib64
Hi Pavlo,
On 3 July 2017 at 16:25, Pavlo Lavrenenko 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 0x7f0d4c26ce7d in ?? () from /lib64/libpypy-c.so
I would try first upgrad
Hello, guys.
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 0x7f0d4c26ce7d in ?? () from /lib64/libpypy-c.so
If I had a proper code sample to reproduce the issue I would have submitte
