<arigo>
still didn't manage to get a working pdb prompt, but adding the line ``#include "Windows.h"`` before the one using wchar_t seems to fix the C compiler error but not the test. I'll let you dig I guess
<mattip>
here is one that has me scratching my head. PyPy + scipy 1.7.0 crashes, this is a minimal reproducer
<mattip>
pypy3-c -c"from scipy.stats._sobol import initialize_direction_numbers as init; init()"
<mattip>
on linux x86_64
<mattip>
it crashes at this line with a memory corruption, the PyUnciodeObject that is "__file__" is corrupted and pypy flails around as if there was some kind of stack overvlow
<mattip>
but if I comment out the 'vinit = dns["vinit"]' code two lines lower, everything works fine
<mattip>
under valgrind it all works fine
<mattip>
why should code two lines lower influence that call?
muke has joined #pypy
<muke>
cfbolz Hey just a quick question for when you get back - looking at the simple gc under 'memory/gc', I can just call the malloc function it has and have it just work for now right? It has a 'NOT_RPYTHON' comment so unsure if I'm looking at the right one
<muke>
if anyone else knows anything about this in the meantime feel free to share though :p
<cfbolz>
muke: (I'm not really here) grep for boehm
<muke>
I thought we were avoiding boehm for now though?
<cfbolz>
muke: no, why?
<cfbolz>
We want to use boehm, it's by far the easiest to support
<muke>
oh I may be getting mixed up - I thought boehm was the one that would require patchpoints
<cfbolz>
No
<muke>
ok, I'll look into using that for now then, thanks
<cfbolz>
Cheers
<mattip>
ok, it seems that it is a stack problem, the cython code has a "cdef int vinit[21201][18]" in the global namespace, and then does
<mattip>
def init(...): global vinit; <read data>; vinit data
<mattip>
which turns into c code like
<mattip>
void init(...) { int __pyx_t_12[21201][18]; <read data>; <assign to __pyx_t_12>; memcpy(vinit, __pyx_t_12, ...);