Skip to content

Semi-random test failure of QTable operations #6291

New issue
New issue
Closed
#6342
Closed
Semi-random test failure of QTable operations#6291
#6342
Labels
Bugtabletestingunits
Milestone
v2.0.3

Description

@bsipocz
bsipocz
opened on Jun 27, 2017

This failure shows up relatively randomly, usually either in the python3.4+np1.9 or python3.5+np.1.11 travis job, but I saw it locally, too with python3.5+np1.12
https://travis-ci.org/astropy/astropy/jobs/247412542#L2795

@mhvk @taldcroft - Is it real, can we do something about it?

Activity

  1. bsipocz
    added
    Bug
    table
    testing
    units
    on Jun 27, 2017
  2. bsipocz
    added this to the v2.0.0 milestone on Jun 27, 2017

  3. pllim commented on Jun 27, 2017

    @pllim
    pllim
    on Jun 27, 2017
    Member

    git blame in astropy/units/quantity.py around the line of interest points to maybe #6137? The other commits are much older.

  4. mhvk commented on Jun 27, 2017

    @mhvk
    mhvk
    on Jun 27, 2017
    Contributor

    Seems somewhat unlikely. Given the sporadic nature, I worry more about the change of info._parent to a weak reference - maybe sometimes the reference has disappeared. @taldcroft?

  5. bsipocz commented on Jun 27, 2017

    @bsipocz
    bsipocz
    on Jun 27, 2017
    MemberAuthor

    now it seems to be disappeared from master PR runs, but was there a few hours ago with no related changes merged since...

  6. taldcroft commented on Jun 27, 2017

    @taldcroft
    taldcroft
    on Jun 27, 2017
    Member

    I have played with this a little. I ran the tests 20+ times locally (macosx + py3.5 + numpy 1.11 / 1.12) and could not reproduce the problem. It is a bit perplexing because (to first order) if there is a problem related to #6277 we should be seeing the AttributeError that comes if you access col.info somewhere and that is a dead weak reference. The try/except in the code is not catching AttributeError.

  7. mhvk commented on Jun 27, 2017

    @mhvk
    mhvk
    on Jun 27, 2017
    Contributor

    Very weird.

  8. bsipocz commented on Jun 27, 2017

    @bsipocz
    bsipocz
    on Jun 27, 2017
    MemberAuthor

    I've just restarted a travis job on v2.0.x branch on py3.4+np1.9 with the failure.

  9. olebole commented on Jun 28, 2017

    @olebole
    olebole
    on Jun 28, 2017
    Member

    I can confirm this failure with my first test build on Debian sid with Python 3.5.3. Test environment as reported in the log:

    • Numpy: 1.12.1
    • Scipy: 0.18.1
    • Matplotlib: 2.0.0
    • h5py: 2.7.0
    • Pandas: not available
    • Cython: 0.25.2
    • Using Astropy options: remote_data: none.

  10. astrofrog commented on Jun 28, 2017

    @astrofrog
    astrofrog
    on Jun 28, 2017
    Member

    Just a wild guess - with weak references, if the weak reference is the last reference to an object, the exact point where the object will be garbage-collected is non-deterministic, so this might be what is happening here? (i.e. something is relying on the attribute existing but it is sometimes getting garbage collected too soon?)

  11. astrofrog commented on Jun 28, 2017

    @astrofrog
    astrofrog
    on Jun 28, 2017
    Member

    One way to test my hypothesis - when creating a weakref, you can add a callback function when the original object is deleted, so this would help find out when exactly this happens and how this correlates with the test failures.

  12. taldcroft commented on Jun 28, 2017

    @taldcroft
    taldcroft
    on Jun 28, 2017
    Member

    Hmm, I ran 20 times on linux (CentOS-6) and could not generate the error:

    platform linux -- Python 3.5.1, pytest-3.1.2, py-1.4.34, pluggy-0.4.0

Running tests with Astropy version 3.0.dev19488.
Running tests in lib.linux-x86_64-3.5/astropy/table docs/table.

Date: 2017-06-28T07:34:47

Platform: Linux-2.6.32-696.1.1.el6.x86_64-x86_64-with-centos-6.9-Final

Executable: /export/tom/anaconda/envs/astropy3-1.2rc1/bin/python

Full Python Version: 
3.5.1 |Continuum Analytics, Inc.| (default, Dec  7 2015, 11:16:01) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]

encodings: sys: utf-8, locale: UTF-8, filesystem: utf-8
byteorder: little
float info: dig: 15, mant_dig: 15

Numpy: 1.12.1
Scipy: 0.19.0
Matplotlib: 2.0.2
h5py: not available
Pandas: not available
Cython: 0.24
Using Astropy options: remote_data: none.

  13. 32 remaining items

  14. bsipocz
    modified the milestones: v2.0.0, v2.0.1 on Jul 7, 2017
  15. bsipocz
    modified the milestones: v2.0.1, v2.0.2 on Jul 28, 2017
  16. bsipocz
    modified the milestones: v2.0.2, v2.0.3 on Sep 7, 2017

  17. mhvk commented on Oct 13, 2017

    @mhvk
    mhvk
    on Oct 13, 2017
    Contributor

    Looking at this because of #6725 - where the xfail on the tests might get reverted. Could this be the same bug that bit @larrybradley (#6703), where there was sometimes a reuse of the format function. If so, then this should be solved by #6714.

  18. bsipocz commented on Dec 5, 2017

    @bsipocz
    bsipocz
    on Dec 5, 2017
    MemberAuthor

    We don't see this issue for a while, so the fix mention above seem to be working. I'm closing it now, but reopen if it pops up again.

  19. bsipocz
    closed this as completedon Dec 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Bugtabletestingunits

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions