homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author josh.r
Recipients josh.r, serhiy.storchaka, vocdetnojz
Date 2016年12月02日.13:52:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1480686744.17.0.0085587641715.issue26861@psf.upfronthosting.co.za>
In-reply-to
Content
You're going to need to provide a real repro; your description is effectively useless. For the record, Python is not precisely pass by reference (it's roughly equivalent to passing a pointer in C, binding the local name to the same pointer, so if you reassign the local name, you lose the reference, but otherwise it behaves like pass-by-reference).
Are you sure the command library doesn't open new connections as needed? In a recursive call scenario, if it goes deep enough, even if it clean up with the recursive call eventually returns, you could still hit the open files limit.
The problem is not copyfile, even if you happen to see copyfile in the traceback. You've got too many open files, and copyfile is the straw that broke the camel's back, but unless you're running 1000 threads doing copyfile simultaneously, it's not responsible for the excess open file handles.
But this is all speculation; the only thing I'm confident of is that copyfile isn't ultimately responsible. We have no idea what's wrong, so you need to provide some sort of minimal repro that exhibits the problem.
History
Date User Action Args
2016年12月02日 13:52:24josh.rsetrecipients: + josh.r, serhiy.storchaka, vocdetnojz
2016年12月02日 13:52:24josh.rsetmessageid: <1480686744.17.0.0085587641715.issue26861@psf.upfronthosting.co.za>
2016年12月02日 13:52:24josh.rlinkissue26861 messages
2016年12月02日 13:52:23josh.rcreate

AltStyle によって変換されたページ (->オリジナル) /