You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test_read_through_table_interface crashes Python on Windows 7 with Anaconda #2100
Unfortunately there is no error message or useful diagnostics immediately available. I will dig further into this once I have some time, unless someone else has time to look into it first.
EDIT: some more details - the error specifically happens when _write_string is called, and then calls _buffer_realloc, upon which it crashes at this line: https://github.com/astropy/astropy/blob/master/astropy/io/votable/src/tablewriter.c#L74 - at this point, n is 512 and sizeof(CHAR) is 2. Not sure what could be happening here. I'll let you take it from here ;)
@astrfrog -- I don't think this is an astropy bug, actually, but a mismatch between the way astropy is compiled if you run setup.py in anaconda vs the way they compile when they build conda packages.
If I navigate to the continuum-provided astropy in site-packages and run the tests with py.test io/votable/table_test.py they succeed on my Win7/64-bit VM.
If I make a new environment and conda remove astropy (just to be sure I don't pick up anything conda-compiled), download the astropy source and python setup.py test I see the same fail that you are seeing and that occurs on appveyor when compilation there is done with mingw.
When conda builds packages, though, it builds them with MSVC (see, e.g. this discussion on the conda list, all the way at the bottom: anaconda uses mingw when you python setup.py test/install, but conda build on windows uses MSVC).
My suggestion would be stick with testing (and supporting) only astropy binaries built with MSVC...now that there exists appveyor, using appveyor to build binary wheels for astropy should be straightforward.
That sounds about right. FWIW I built all the binary Windows installers for Astropy with mingw. But I don't think those are used very much to begin with (though maybe it would be better to build them with MSVC)...
Once appveyor is up and running it can be configured to build binaries (I've seen recipes for wheels and for conda packages on appveyor, the EXEs shouldn't be too bad); that would presumably be tied to tags but would need to be sorted out later.
Activity
astrofrog commentedon Feb 15, 2014
cc @mdboom since this is in
io.votablemdboom commentedon May 9, 2014
Is this still an issue?
astrofrog commentedon May 9, 2014
@mdboom - yes, but there is no information beyond just crashing. Not very helpful. Do you have a VM that you can try and reproduce this on?
mdboom commentedon May 9, 2014
I don't have access to it while telecommuting. I can try this at the office on Tuesday.
astrofrog commentedon May 9, 2014
This is not urgent btw (since no users have actually reported the issue, and I was only testing, not using Windows) so no problem.
astrofrog commentedon Jul 15, 2014
I see the same issue in
test_regressioninvo_test.py. Specifically, this line causes the segfault:https://github.com/astropy/astropy/blob/master/astropy/io/votable/tests/vo_test.py#L139
Digging into to_xml to see if I can find where the error occurs.
astrofrog commentedon Jul 15, 2014
@mdboom - the segfault happens in https://github.com/astropy/astropy/blob/master/astropy/io/votable/tree.py#L2744
EDIT: some more details - the error specifically happens when
_write_stringis called, and then calls_buffer_realloc, upon which it crashes at this line: https://github.com/astropy/astropy/blob/master/astropy/io/votable/src/tablewriter.c#L74 - at this point,nis 512 andsizeof(CHAR)is 2. Not sure what could be happening here. I'll let you take it from here ;)astrofrog commentedon Jul 16, 2014
@mdboom - just for info, this also bombs on appveyor: https://ci.appveyor.com/project/Cadair/astropy/build/job/5j4em4lrnmdr24g0
mwcraig commentedon Aug 9, 2014
@astrfrog -- I don't think this is an astropy bug, actually, but a mismatch between the way astropy is compiled if you run setup.py in anaconda vs the way they compile when they build conda packages.
If I navigate to the continuum-provided astropy in site-packages and run the tests with
py.test io/votable/table_test.pythey succeed on my Win7/64-bit VM.If I make a new environment and
conda remove astropy(just to be sure I don't pick up anything conda-compiled), download the astropy source andpython setup.py testI see the same fail that you are seeing and that occurs on appveyor when compilation there is done with mingw.When conda builds packages, though, it builds them with MSVC (see, e.g. this discussion on the conda list, all the way at the bottom: anaconda uses mingw when you python setup.py test/install, but conda build on windows uses MSVC).
My suggestion would be stick with testing (and supporting) only astropy binaries built with MSVC...now that there exists appveyor, using appveyor to build binary wheels for astropy should be straightforward.
astrofrog commentedon Aug 9, 2014
@mwcraig - thanks for your insight into this!
@embray - since you've also had experience with Windows, in the light of what @mwcraig found, shall we close this?
embray commentedon Aug 11, 2014
That sounds about right. FWIW I built all the binary Windows installers for Astropy with mingw. But I don't think those are used very much to begin with (though maybe it would be better to build them with MSVC)...
mwcraig commentedon Aug 11, 2014
Once appveyor is up and running it can be configured to build binaries (I've seen recipes for wheels and for conda packages on appveyor, the EXEs shouldn't be too bad); that would presumably be tied to tags but would need to be sorted out later.
astrofrog commentedon Aug 11, 2014
Ok, sounds good! I'll close this for now in that case.