Julia: EXCEPTION_ACCESS_VIOLATION from ccall on x86 Windows since Julia 1.2.0-DEV.641

[tkf]

PyCall's CI on x86 Windows with Julia nightly has been failing since (at least) Julia 1.2.0-DEV.641 when calling CPython API via ccall (logs). This still happened in the latest tests on PyCall master with Julia 1.3.0-DEV.2 (logs). The last success was with Julia 1.2.0-DEV.570 (logs). Re-running this last succeeded version of PyCall with Julia 1.3.0-DEV.151 failed (logs). Can it be some ccall-related issue in Julia?

The backtrace error starts with (example from here):

Exception: EXCEPTION_ACCESS_VIOLATION at 0xfef2350 -- unknown function (ip: 0FEF2350)
in expression starting at C:\projects\pycall-jl\test\runtests.jl:29
unknown function (ip: 0FEF234F)
PyObject_Call at C:\Users\appveyor\.julia\conda\3\python36.dll (unknown line)
__pycall! at C:\projects\pycall-jl\src\exception.jl:81
_pycall! at C:\projects\pycall-jl\src\pyfncall.jl:29
_pycall! at C:\projects\pycall-jl\src\pyfncall.jl:11 [inlined]
#pycall#110 at C:\projects\pycall-jl\src\pyfncall.jl:86 [inlined]
pycall at C:\projects\pycall-jl\src\pyfncall.jl:86
unknown function (ip: 0FF8E62B)
jl_apply_generic at /home/Administrator/buildbot/worker/package_win32/build/src/home/Administrator/buildbot/worker/package_win32/build/src\gf.c:2197

where I believe the corresponding ccall happened here.

(Ref: https://github.com/JuliaPy/PyCall.jl/issues/687)

[stevengj]

Is there an easy way to do a git bisect on AppVeyor?

Can anyone with Windows reproduce this locally?

[tkf]

This is still reproducible in Julia 1.2.0-rc1: https://ci.appveyor.com/project/tkf/pycall-jl/builds/24940269

[tkf]

This is still reproducible in Julia 1.2.0-rc2: https://ci.appveyor.com/project/tkf/pycall-jl/builds/26035307

[JeffBezanson]

Maybe try with ALWAYS_COPY_STACKS defined in options.h?

[tkf]

I don't have a Windows setup so I can't try it locally. I can run things in appveyor if there is an easy way to do this like a prebuilt binary. In principle it's possible to build Julia in appveyor but that would be a very frustrating try-and-error process with a long delay in feedback. So, I'd like to avoid this path. If there is no interest from Windows+PyCall users maybe this shouldn't be blocking 1.2 release.

[jebej]

PyCall is definitely important, in particular for PyPlot.

[JeffBezanson]

I can reproduce this in a windows vm.

[JeffBezanson]

Enabling ALWAYS_COPY_STACKS seems to be even worse, giving a 0x80000001 STATUS_GUARD_PAGE_VIOLATION...

[JeffBezanson]

Bisect points to 8c44566 (same as #32607).

[JeffBezanson]

Narrowed down to pycall(PyObject(x -> x + 1), PyAny, 314158).