Neil Schemenauer added the comment:
Thanks, I'm indeed interested. Most credit goes to Christian for advancing
this.
For the missing stdatomic.h, would it be appropriate to have an autoconfig
check for it? Can just disable mimalloc if it doesn&#x
Neil Schemenauer added the comment:
My preference would be for --with-mimalloc=yes in an upcoming release. For
platforms without the required stdatomic.h stuff, they can manually specify
--with-mimalloc=no. That will make them aware that a future release of Python
might no longer build (if
Neil Schemenauer added the comment:
I made the changes as suggest by Guido. Commited as SVN rev 58226.
Thanks for the patch.
--
nosy: +nas
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Neil Schemenauer added the comment:
It looks to me like fp_readl is no longer working as designed and the
patch is not really the right fix. The use of "decoding_buffer" is
tricky and I think the conversion to bytes screwed it up. It might be
clearer to have a separate "de
Neil Schemenauer added the comment:
I'm late to the party but looks like Mark has a good handle on the issues. I
would recommend not changing behavior in a bugfix release. I'm pretty sure
code "in the wild" would be broken.
--
__
Neil Schemenauer added the comment:
Closing this bug. I don't think it makes sense to change the mhlib module in
bugfix release. My patch is fairly simple but not simple enough to make me
feel comfortable.
--
resolution: -> wont fix
status: open -
New submission from Neil Schemenauer :
I'm trying implement some saner module shutdown procedure (similar to issue
812369). One of the many problems I've run into is that the GC doesn't know
about the m_copy attribute of modules.
I think the attached patch is correct. tp_tr
New submission from Neil Schemenauer :
It looks to me like initstdio leaks a reference to "open". AFAIK,
PyObject_SetAttrString() does not steal a reference.
--
assignee: pitrou
components: Interpreter Core
files: initstdio_refleak.txt
messages: 120008
nosy: nascheme, pitro
Neil Schemenauer added the comment:
Oops, my patch doesn't work since m_base can be shared by more than one module
instance. I guess a different solution would be to cleanup the m_copy
references on interpreter shutdown. Somehow they would have to be found t
Neil Schemenauer added the comment:
The attached patch seems better. The copies of module dicts stored in the
interpreter state are dereferenced when the interpreter shuts down.
--
Added file: http://bugs.python.org/file19509/module_m_copy2.txt
New submission from Neil Schemenauer :
I think it should be safe to remove some backwards compatibility cruft. This
was introduced during the 2.3 development cycle.
--
files: gc_cruft.txt
messages: 120554
nosy: nascheme
priority: low
severity: normal
status: open
title: Remove ancient
Neil Schemenauer <[EMAIL PROTECTED]> added the comment:
Looks like this has exposed some ugly code. From setup.py:
# Figure out the location of the source code for extension modules
# (This logic is copied in distutils.test.test_sysconfig,
# so building in a separate directory do
Neil Schemenauer <[EMAIL PROTECTED]> added the comment:
I think my previous patch combined with sysconfig_builddir.patch fixes
this issue. Someone will need to test on other platforms. Note that
the messy code in setup.py and in the tests should still be cleaned up.
BTW, distutils is a
Neil Schemenauer <[EMAIL PROTECTED]> added the comment:
One final patch for today (get_python_inc.patch). The patch combines my
previous two patches and also cleans up some ugly code in setup.py and
test_sysconfig.py. The source of the ugliness was that get_python_inc()
did not wor
Changes by Neil Schemenauer <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10659/test_ext_src.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Neil Schemenauer <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10660/sysconfig_builddir.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Neil Schemenauer added the comment:
Looks like the 2.7 patch has a spurious change to /Lib/unittest/runner.py.
--
nosy: +nascheme
___
Python tracker
<http://bugs.python.org/issue7
Neil Schemenauer added the comment:
Here is an updated set of patches that includes the ceval_gil.h file as well as
the documentation changes.
--
Added file: http://bugs.python.org/file15974/gil-2.7.txt
___
Python tracker
<http://bugs.python.
Changes by Neil Schemenauer :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue4698>
___
___
Python-bugs-list
Changes by Neil Schemenauer :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue1220756>
___
___
Python-bugs-
New submission from Neil Schemenauer :
Btrfs does not maintain a link count for directories (MacOS does the same I
think). That confuses mhlib.py because it uses os.stat().st_nlinks as an
optimization.
The attached patch removes the optimization and make test_mhlib pass on Btrfs
(and
Neil Schemenauer added the comment:
On Sat, Jan 23, 2010 at 06:09:33PM +, Antoine Pitrou wrote:
> The documentation mentions that mhlib is deprecated and mailbox
> should be used instead. Is there any point in trying to fix it?
It looks like Btrfs will eventually conform to tradi
Neil Schemenauer added the comment:
On Sun, Jan 24, 2010 at 01:25:18AM +, Antoine Pitrou wrote:
> That wasn't really my question. What I ask is: since mhlib is
> deprecated, why do we need to fix it while people are encouraged to use
> mailbox instead?
Sorry, I don't
New submission from Neil Schemenauer :
The commit for issue #7868 added the following line to test_logging:
print >> open('/tmp/tmp.txt', 'w'), type(logger)
I'm not sure if that was intentional but it should be fixed. For one, that
path does not necessarily e
New submission from Neil Schemenauer :
Lib/test/test_distutils.py crashes if Python was built in a directory other
than the source directory. Using a separate build directory is handy if you
are building Python with different sets of configure options since you only
need one copy of the
Neil Schemenauer added the comment:
On Sat, Dec 08, 2007 at 05:14:45AM -, Alexandre Vassalotti wrote:
> The PEP has been deferred and the patch is out of date. So, is this
> change still wanted?
I still think it would make things easier for people using Unicode
with Python 2.x. H
Changes by Neil Schemenauer <[EMAIL PROTECTED]>:
--
status: open -> closed
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue628842>
___
Pyt
Neil Schemenauer <[EMAIL PROTECTED]> added the comment:
On Sun, Mar 23, 2008 at 04:17:12PM +, Antoine Pitrou wrote:
> Armin, if you still care about the compiler package, could you (or some
> other pypy coder) take a look at #2459? As part of the patch, it
> rewrites the f
Neil Schemenauer <[EMAIL PROTECTED]> added the comment:
On Thu, Mar 20, 2008 at 08:49:32PM +, Sean Reifschneider wrote:
> Is a straightforward patch, but I'd like NAS to comment on the change in
> behavior. Probably would also need a documentation change, are you up
> f
Neil Schemenauer <[EMAIL PROTECTED]> added the comment:
The original code is pretty icky. I'm attaching a patch that improves
it, IMO. Before the elapsed time was only shown if garbage was found.
I think it should always be shown if DEBUG_STATS is set.
--
nosy: +nas
Added
Neil Schemenauer <[EMAIL PROTECTED]> added the comment:
On Tue, Mar 25, 2008 at 09:18:38AM +, Armin Rigo wrote:
> The situation is that by now PyPy has found many many more bugs in
> trying to use the compiler package to run the whole stdlib and
> real-world applications. Wha
New submission from Neil Schemenauer <[EMAIL PROTECTED]>:
Building in a separate directory got broken at some point. The code is
hairy but it looks like the source of the problem was a lame
sysconfig.get_python_inc() function. The attached patches fix things
and hopefully do not introdu
Changes by Neil Schemenauer <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file11838/get_python_inc2.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Neil Schemenauer <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11837/get_python_inc.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Neil Schemenauer <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file11839/get_python_inc2.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Neil Schemenauer <[EMAIL PROTECTED]>:
The ihooks module was updated when the absolute imports feature was
implemented. At a minimum, I guess the import_module() methods in that
module would need to have "level=-1" keyword arguments added. The only
library
Neil Schemenauer <[EMAIL PROTECTED]> added the comment:
Issue 4151 contains a similar patch but it cleans up more code, IMHO.
--
nosy: +nas
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Neil Schemenauer <[EMAIL PROTECTED]> added the comment:
[Roumen Petrov]
> Modification for test_build_ext.py from above mentioned issue break
> non-posix builds.
Without that change the test fails on Unix platforms when the build is
not done inside the source directory. I guess
Neil Schemenauer added the comment:
I committed my proposed changes in several chunks, ending with r69305.
I think building in a separate directory again works and that non-POSIX
platforms are not adversely affected by this change.
___
Python tracker
<h
Neil Schemenauer added the comment:
I committed my proposed changes in several chunks, ending with r69305.
I think building in a separate directory again works and that non-POSIX
platforms are not adversely affected by this change.
--
nosy: +nascheme
resolution: -> fixed
status: o
Changes by Neil Schemenauer :
___
Python tracker
<http://bugs.python.org/issue4151>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/o
Changes by Neil Schemenauer :
--
assignee: -> nascheme
nosy: +nascheme
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.o
Neil Schemenauer added the comment:
Roumen, thanks for reporting the bug. It seems that distutils requires
an absolute path (although I didn't waste time digging too deep into the
issue).
___
Python tracker
<http://bugs.python.org/i
New submission from Neil Schemenauer :
The following code was added to Makefile.pre.in when ctypes was merged:
find $(srcdir)/build -name 'fficonfig.h' -exec rm -f {} ';' || true
find $(srcdir)/build -name 'fficonfig.py' -exec rm -f {} ';' || tr
Neil Schemenauer added the comment:
Thanks Antoine. For some reason I don't think I ever got an email about
this issue. I did some further cleanups and optimizations. Committed
as SVN rev 69373.
Lib/compiler is still in need of some fixing since it doesn't handle
decorators and
Neil Schemenauer added the comment:
Looks like this has already been fixed in SVN rev 53575.
--
resolution: -> out of date
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Neil Schemenauer :
--
assignee: -> nascheme
nosy: +nascheme
___
Python tracker
<http://bugs.python.org/issue1754094>
___
___
Python-bugs-list mai
Neil Schemenauer added the comment:
Fixed in SVN rev 69394 (finally). This was done by having the symbol
table differentiate between explicit and implicit globals.
--
assignee: jhylton -> nascheme
nosy: +nascheme
resolution: -> fixed
status: open -&g
Changes by Neil Schemenauer :
--
assignee: jhylton -> nascheme
nosy: +nascheme
___
Python tracker
<http://bugs.python.org/issue999444>
___
___
Python-bugs-lis
Changes by Neil Schemenauer :
--
assignee: -> nascheme
nosy: +nascheme
___
Python tracker
<http://bugs.python.org/issue5064>
___
___
Python-bugs-list mai
New submission from Neil Schemenauer :
I noticed that it would be nice to have a temporary directory context
manager while trying to fix a broken unittest. The attached patch
provides a pretty minimal implementation. There appears to be lots of
unit tests that could use such a thing (just
Neil Schemenauer added the comment:
On Thu, Feb 12, 2009 at 01:32:37PM +, Matthias Klose wrote:
> still seen on the 2.6 branch. applying r69374 on the branch doesn't fix
> it there.
The fix is spread over a number of commits: r69374, r69322, r69315,
r69305, r69304, r69303,
Neil Schemenauer added the comment:
New version of the patch. Added a __del__ method that hopefully works
reliably. Added NEWS and an example of TemporaryFile as a context
manager. I did not change more tests to use TemporaryDirectory since I
understand hit-and-run modernization of code is
Neil Schemenauer added the comment:
Argh, it's like pulling a sweater thread. The stat.S_ISDIR function
uses the S_IFDIR global so I would have write my own. This does not
look like good maintainable code, IMO.
Maybe there should be a special flag modules can set to make them get
cl
Neil Schemenauer added the comment:
This sounds like a nice idea. The current cleanup procedure in
pythonrun.c is pretty lame since it can play havoc with __del__ methods
(e.g. if they run after globals have been cleared).
I've updated the patch to work with the current SVN head. Pro
Neil Schemenauer added the comment:
A few comments from the "peanut gallery". Thanks to Victor and Pablo for doing
the hard work of investigating this bug.
First, it has been a long time since Tim and I first developed gcmodule.c. So,
some of my understanding may be inaccurate d
Neil Schemenauer added the comment:
I think the problem with your logic is that the weakref to F is part of the
garbage set. So, handle_finalizers() should detect that and clear the
finalizer rather than call it. Once we get to delete_garbage() and start
calling tp_clear(), we can'
Neil Schemenauer added the comment:
Victor:
> I'm surprised that the function would be seen as "unreachable" if
> it's reference counter was equal to 135:
If all those references are contained within that garbage set, it is
possible.
Pablo:
> For the weakre
Neil Schemenauer added the comment:
I hacked up my copy of CPython to add flags to PyObject to see the
GC state of objects. That makes it easier to know if an object is
in the 'unreachable' list or not.
> We must know that F is trash, else we never would have called tp_clear(
Neil Schemenauer added the comment:
Since W is in the unreachable set, we should not be executing its callback.
Would the attached rough patch (gc_disable_wr_callback.txt) be a possible fix?
When we find W inside handle_weakrefs(), we mark it as trash and will not
execute the callback
Neil Schemenauer added the comment:
> Fleshing out something I left implicit: if there's a trash object T
> with a finalizer but we don't KNOW it's trash, we won't force-run its
> finalizer before delete_garbage starts either. Then, really the same
> thing: we
Neil Schemenauer added the comment:
> We can have finalizer code running during delete_garbage(). That
> code should not have access to non-valid objects. Weakrefs seem be
> a way to violate that. handle_weakrefs() take care of some of them
> but it seems there are other issues.
Change by Neil Schemenauer :
--
pull_requests: +16083
pull_request: https://github.com/python/cpython/pull/16495
___
Python tracker
<https://bugs.python.org/issue38
Neil Schemenauer added the comment:
> Why setting it back to release blocker? As far as I recall, this issue is not
> a Python 3.8 regression. The regression which triggered this old and existing
> bug has been fixed, see previous comments.
I leave it up to our glorious release m
Neil Schemenauer added the comment:
Oops, I linked to wrong PR, my proposed fix is GH-16495. It is the same as
what Tim suggests in his last comment.
--
___
Python tracker
<https://bugs.python.org/issue38
Neil Schemenauer added the comment:
> Would [func tp_clear] help with memory usage in functions or was BPO-33418
> addressed in another way since?
Having a tp_clear for all container objects that can be involved in reference
cycles will help the GC free memory. BPO-33418 may be con
Neil Schemenauer added the comment:
> Is introducing tp_clear on functions a thing that has ABI consequences? In
> other words, if we take our time on this, would it land in 3.8.1 or 3.9.0?
I think it should not have ABI consequences. However, I see the addition of
tp_clear as
Change by Neil Schemenauer :
--
pull_requests: +16092
pull_request: https://github.com/python/cpython/pull/16502
___
Python tracker
<https://bugs.python.org/issue38
Change by Neil Schemenauer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Neil Schemenauer added the comment:
I created GH-16502. I'm not exactly sure of the process of making a revert on
a branch like '3.8' so hopefully it is correct. The code change is exactly
what has been reverted in 3.8. The net effect will be as if the revert
Change by Neil Schemenauer :
--
nosy: +benjamin.peterson, larry, ned.deily
versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue38
Neil Schemenauer added the comment:
I worked some on trying to create a unit test this evening. Attached is my
best result so far (gc_weakref_bug_demo.py). It requires that you enable the
'xx' module so we have a container object without tp_traverse. We should
probably
Change by Neil Schemenauer :
--
pull_requests: +16095
pull_request: https://github.com/python/cpython/pull/16502
___
Python tracker
<https://bugs.python.org/issue33
Neil Schemenauer added the comment:
Łukasz, is there some reason you removed old versions (2.7, 3.6, etc)? The bug
is present on those versions of Python and it should be trivial to backport the
fix. If those branches are maintained, I think we should fix it.
Attached is a small test
Change by Neil Schemenauer :
--
pull_requests: +16348
pull_request: https://github.com/python/cpython/pull/16788
___
Python tracker
<https://bugs.python.org/issue38
Neil Schemenauer added the comment:
> It's fundamentally insane to expect any gc to work perfectly when it may be
> blind to what the object graph _is_.
I'm often amazed it works at all, let alone perfectly. ;-P
This did trigger me to think of another possible problem. I se
Neil Schemenauer added the comment:
New changeset 392a13bb9346331b087bcd8bb1b37072c126abee by Neil Schemenauer in
branch 'master':
bpo-38006: Add unit test for weakref clear bug (GH-16788)
https://github.com/python/cpython/commit/392a13bb9346331b087bcd8bb1b370
Neil Schemenauer added the comment:
New changeset 85b6b70589c187639aeebc560d67e9cc04abb4d8 by Neil Schemenauer in
branch 'master':
bpo-37448: Use radix tree for pymalloc address_in_range(). (GH-14474)
https://github.com/python/cpython/commit/85b6b70589c187639aeebc560d67e9
Change by Neil Schemenauer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Neil Schemenauer added the comment:
I've merged PR 14474 so you can just test with an up-to-date "main" branch and
see if that fixes the problem. I would expect it should fix the problem since
with the radix tree arena tracking, no memory unsanitary behaviour remains.
Neil Schemenauer added the comment:
Seems this failure might be back. At least, the traceback looks quite similar
to me.
The buildbot failed with this:
heads/master:85b6b70589, Mar 29 2021, 22:53:15
0:05:26 load avg: 3.95 [426/427] test_tokenize passed (56.0 sec) -- running:
test_asyncio
Neil Schemenauer added the comment:
It seems to not be specific to S390, same kind of failure on the PPC64LE RHEL8
LTO + PGE 3.x tester:
Exception ignored in:
Traceback (most recent call last):
File
"/home/buildbot/buildarea/3.x.cst
Neil Schemenauer added the comment:
> If MTE is actually being used, system software assigns "random" values to 4
> of the higher-order bits.
Oh, interesting.
Two ideas about handling that: we could change our assertion check to be
different on ARM platforms that we kno
Change by Neil Schemenauer :
--
nosy: +nascheme
___
Python tracker
<https://bugs.python.org/issue42972>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Neil Schemenauer :
Note: This is a proof of concept and not ready for merging as is.
This is based on 'frozen_modules' from Jeethu Rao , via
Larry Hastings. Larry's git branch was:
g...@github.com:larryhasti
Change by Neil Schemenauer :
--
keywords: +patch
pull_requests: +25161
pull_request: https://github.com/python/cpython/pull/26571
___
Python tracker
<https://bugs.python.org/issue44
Neil Schemenauer added the comment:
It seems to me the old behaviour (don't forward hash) was done for good
reasons. If the referent might go away, it is not valid to use it as a dict
key since the hash and eq result changes. If it can't go away, what reason is
there to use a w
Change by Neil Schemenauer :
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Neil Schemenauer :
The fix for bpo-33930 includes a somewhat mysterious comment:
// The Py_TRASHCAN mechanism requires that we be able to
// call PyObject_GC_UnTrack twice on an object.
I wonder if we can just integrate the untrack into the body of the trashcan
Neil Schemenauer added the comment:
I'm thinking that the explicit call to PyObject_GC_UnTrack should be made
unnecessary by integrating it into the trashcan code. That way, we avoid
someone else running into this kind of bug in the future. See bpo-44881.
--
nosy: +nas
Change by Neil Schemenauer :
--
keywords: +patch
pull_requests: +26201
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/27718
___
Python tracker
<https://bugs.python.org/issu
Neil Schemenauer added the comment:
Extensions that call PyObject_GC_UnTrack before calling Py_TRASHCAN_BEGIN will
still work, they will just take a very minor performance hit. I don't think it
is worth the trouble to introduce new macros for that reason. Extensions that
really care
Neil Schemenauer added the comment:
For examples of bugs caused by forgetting the untrack calls, see bpo-31095.
--
___
Python tracker
<https://bugs.python.org/issue44
Neil Schemenauer added the comment:
Since C99 is now allowed, perhaps we should suggest that declarations go after
Py_TRASHCAN_BEGIN, e.g.
mytype_dealloc(mytype *p)
{
Py_TRASHCAN_BEGIN(p, mytype_dealloc)
... declarations go here ...
... The
Neil Schemenauer added the comment:
I was thinking about this more today and I think the better fix is to actually
build the trashcan mechanism into _Py_Dealloc(). Requiring that types opt-in
to the trashcan mechanism by using the trashcan macros is not ideal.
First, the trashcan macros
New submission from Neil Schemenauer :
This is a WIP/proof-of-concept of doing away with Py_TRASHCAN_BEGIN and
Py_TRASHCAN_END and instead integrating the functionality into _Py_Dealloc.
There are a few advantages:
- all container objects have the risk of overflowing the C stack if a long
Change by Neil Schemenauer :
--
keywords: +patch
pull_requests: +26218
pull_request: https://github.com/python/cpython/pull/27738
___
Python tracker
<https://bugs.python.org/issue44
Neil Schemenauer added the comment:
I wrote a proof-of-concept as bpo-44897. PR 27718 (this issue) might a
slightly better performance but I like the other one better because it doesn't
expose so much implementation detail to extension types. Either of them
require careful review b
Neil Schemenauer added the comment:
> The problem of PyObject_GC_UnTrack() is just the most visible effect of the
> trashcan mecanism: tp_dealloc can be called twice, and this is *not* expected
> by the tp_dealloc API.
The fact that Py_TRASHCAN_BEGIN and Py_TRASHCAN_END can cause t
Neil Schemenauer added the comment:
> I think in any case we should benchmark this because this will affect *all*
> GC types if I understand correctly and the TS mechanism had shown slowdowns
> before
We definitely need to benchmark. I would guess that adding trashcan protection
1 - 100 of 375 matches
Mail list logo
