# lsst_py3 CI failure due to meas_extensions_ngmix

XMLWordPrintable

## Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
None
• Story Points:
2
• Sprint:
DRP S17-3
• Team:
Data Release Production

## Description

Nate Pease points out that the lsst_py3 Jenkins build is currently failing and has been since build #454 (regardless of the misleading red circles on Jenkins). Reported error is:

 ====================================================================== FAIL: testLeaks (__main__.TestMemory) !Check for memory leaks in the preceding tests ---------------------------------------------------------------------- Traceback (most recent call last):  File "/home/jenkins-slave/workspace/stack-os-matrix/label/centos-7/python/py3/lsstsw/stack/Linux64/utils/12.1-5-g648ee80+2/python/lsst/utils/tests.py", line 161, in testLeaks  self.fail("Leaked %d block%s" % (nleak, plural)) AssertionError: Leaked 13 blocks   ---------------------------------------------------------------------- Ran 10 tests in 0.688s   FAILED (failures=1, skipped=2)  Number of calls to function has reached maxfev = 10.  Number of calls to function has reached maxfev = 10.  Number of calls to function has reached maxfev = 10.  Number of calls to function has reached maxfev = 10. 

## Activity

Hide
Russell Owen added a comment -

Please see DM-9433. The implicit capture seemed reasonable to whoever wrote the original code, but it didn't work in Python 3 due to an obscure change in how long exceptions hang around. I prefer the explicit capture by far, since Python apparently uses late binding for local variables.

Show
Russell Owen added a comment - Please see DM-9433 . The implicit capture seemed reasonable to whoever wrote the original code, but it didn't work in Python 3 due to an obscure change in how long exceptions hang around. I prefer the explicit capture by far, since Python apparently uses late binding for local variables.
Hide
John Swinbank added a comment -

I disagree with you about what the best approach here is, but I don't think it's worth wasting electrons arguing about, so I propose to do effectively what Tim Jenness suggested on GitHub. I won't hard-code a RuntimeError, since I think it's more helpful to pass the original exception to the author.

One thing I'm not happy about is the supposed "better" solution for Python 3. I would genuinely never have guessed that you wrote it that way to make it explicit that you were capturing the variable; I wasted quite some time (and eventually asked you for help, as above) trying to work out what was going on. I propose to remove this comment entirely.

Are you happy with that approach?

Show
John Swinbank added a comment - I disagree with you about what the best approach here is, but I don't think it's worth wasting electrons arguing about, so I propose to do effectively what Tim Jenness suggested on GitHub. I won't hard-code a RuntimeError , since I think it's more helpful to pass the original exception to the author. One thing I'm not happy about is the supposed "better" solution for Python 3. I would genuinely never have guessed that you wrote it that way to make it explicit that you were capturing the variable; I wasted quite some time (and eventually asked you for help, as above) trying to work out what was going on. I propose to remove this comment entirely. Are you happy with that approach?
Hide
Russell Owen added a comment -

That will be fine.

Show
Russell Owen added a comment - That will be fine.
Hide
John Swinbank added a comment -

Thanks; merged.

Show
John Swinbank added a comment - Thanks; merged.
Hide
Russell Owen added a comment -

For the record: my main worry about the old method (that worked in Python 2 and Python 3) and the variant of copying the exception (that you were proposing) is that due to late binding is that the variable holding the exception can be rewritten by other. This is much more likely if a generic name such as "e" (the original code) is used. Still..it requires 3 things to stick around (a variable, a function and a class), when just the function and class are required.

So...with a suitable name I'd be OK with late binding, but I think the current code is easier to understand, even if it is more wordy.

Show
Russell Owen added a comment - For the record: my main worry about the old method (that worked in Python 2 and Python 3) and the variant of copying the exception (that you were proposing) is that due to late binding is that the variable holding the exception can be rewritten by other. This is much more likely if a generic name such as "e" (the original code) is used. Still..it requires 3 things to stick around (a variable, a function and a class), when just the function and class are required. So...with a suitable name I'd be OK with late binding, but I think the current code is easier to understand, even if it is more wordy.

## People

• Assignee:
John Swinbank
Reporter:
John Swinbank
Reviewers:
Russell Owen
Watchers:
John Swinbank, Russell Owen, Tim Jenness