Rocksolid Light

Welcome to RetroBBS

mail  files  register  newsreader  groups  login

Message-ID:  

Are we running light with overbyte?

devel / comp.lang.python / Puzzling behaviour of Py_IncRef

SubjectAuthor
o Puzzling behaviour of Py_IncRefTony Flury

1
Puzzling behaviour of Py_IncRef

<mailman.225.1642589949.3079.python-list@python.org>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=21173&group=comp.lang.python#21173

  copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: tony.flury@btinternet.com (Tony Flury)
Newsgroups: comp.lang.python
Subject: Puzzling behaviour of Py_IncRef
Date: Wed, 19 Jan 2022 10:57:30 +0000
Lines: 85
Message-ID: <mailman.225.1642589949.3079.python-list@python.org>
References: <042d2815-628c-e6b1-1eda-1e385dc26bcc@btinternet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.uni-berlin.de tA/FiMjJT8lPMs39fUboTA4jrMCcTY2V/sp1gGYhBQww==
Return-Path: <tony.flury@btinternet.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
Authentication-Results: mail.python.org; dkim=pass
reason="2048-bit key; unprotected key"
header.d=btinternet.com header.i=@btinternet.com header.b=hNCVCBsJ;
dkim-adsp=pass; dkim-atps=neutral
X-Spam-Status: OK 0.016
X-Spam-Evidence: '*H*': 0.97; '*S*': 0.00; 'def': 0.04; 'traceback':
0.04; '(most': 0.05; 'last):': 0.05; 'variable': 0.05; 'fails':
0.09; 'skip:* 30': 0.09; 'assert': 0.16; 'call,': 0.16;
'incremented': 0.16; 'instance': 0.16; 'node': 0.16; 'nodes':
0.16; 'purely': 0.16; 'skip:" 70': 0.16; 'static': 0.16; 'tree,':
0.16; 'variable,': 0.16; '\xc2\xa0before': 0.16; 'problem': 0.16;
'python': 0.16; 'code.': 0.17; 'to:addr:python-list': 0.20;
'problem,': 0.22; 'skip:_ 10': 0.22; 'code': 0.23; 'extension':
0.25; 'do,': 0.26; 'normally': 0.26; 'function': 0.27; 'done':
0.28; 'expect': 0.28; 'output': 0.28; 'wrong': 0.28; 'header:User-
Agent:1': 0.30; 'module': 0.31; "doesn't": 0.32; '(as': 0.32;
'attaching': 0.32; 'objects': 0.32; 'received:192.168.1': 0.32;
'but': 0.32; 'there': 0.33; 'someone': 0.34; 'trying': 0.35;
'count': 0.36; 'change': 0.36; "it's": 0.37; 'this.': 0.37;
'received:192.168': 0.37; 'though': 0.37; 'file': 0.38; 'two':
0.39; 'still': 0.40; 'artificial': 0.40; 'explain': 0.40;
'received:213': 0.40; 'both': 0.40; 'should': 0.40; 'reference':
0.60; 'method': 0.61; 'skip:\xc2 10': 0.62; 'true': 0.63; 'skip:t
20': 0.66; 'worked': 0.67; 'skip:t 30': 0.67; 'live': 0.68;
'order': 0.69; 'temporarily': 0.69; 'within': 0.69; '2nd': 0.70;
'note:': 0.71; 'little': 0.73; '8bit%:100': 0.76; 'exposed': 0.76;
'(that': 0.84; 'garbage': 0.84; 'increments': 0.84; 'method,':
0.84; 'skip:= 70': 0.84
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com;
s=btmx201904; t=1642589852;
bh=nzlEtvBoNr7PqGw2YAW5cUzoFu4XzlqWaik2NJzASEg=;
h=To:From:Subject:Message-ID:Date:MIME-Version;
b=hNCVCBsJ6WSPwDTH27QvNMZvURcAVZRj0BeU0P9BnfISrdyA7u/1MxNz306RMz5TxMrM0HyryZGpmeL71YVEgu9M9z6CSlGkijRUomHQwJ8Ly9xapeIf8H/gzZKG6b/KWMM0/RS2je31rVpgCbsWAKd4zeVbai8STKiXRurNzXxvdN66lJvF8CRz3KEjRBA57CjGQvqRkmUSq5jBlxfaQ46bJXnCDCHE8Z4hqXt79Nua3MNwqQPcNYnTQnShh6CgjEN5TIGUBhAhOctoeBNe6bZNdTHmjC3pv5xi+a8oZsZ5blW6+NMbVdC2i/NOyA0AAtCzBzIE/qSRbXNVvG7O1g==
Authentication-Results: btinternet.com;
auth=pass (PLAIN) smtp.auth=tony.flury@btinternet.com;
bimi=skipped
X-SNCR-Rigid: 613A8CC310FB79FE
X-Originating-IP: [81.153.144.133]
X-OWM-Source-IP: 81.153.144.133 (GB)
X-OWM-Env-Sender: tony.flury@btinternet.com
X-VadeSecure-score: verdict=clean score=0/300, class=clean
X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvvddrudehgddvvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepvffhuffkffgfgggtsegrtderredtfeejnecuhfhrohhmpefvohhnhicuhfhluhhrhicuoehtohhnhidrfhhluhhrhiessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeefgeejfedtvdevteeutedtgfegheegledvheekheeujefhfefgfeejuedvgefhudenucfkphepkedurdduheefrddugeegrddufeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurdejiegnpdhinhgvthepkedurdduheefrddugeegrddufeefpdhmrghilhhfrhhomhepthhonhihrdhflhhurhihsegsthhinhhtvghrnhgvthdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopehphihthhhonhdqlhhishhtsehphihthhhonhdrohhrgh
X-RazorGate-Vade-Verdict: clean 0
X-RazorGate-Vade-Classification: clean
X-SNCR-hdrdom: btinternet.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Content-Language: en-US
X-Content-Filtered-By: Mailman/MimeDel 2.1.39
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: General discussion list for the Python programming language
<python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>,
<mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <https://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>,
<mailto:python-list-request@python.org?subject=subscribe>
X-Mailman-Original-Message-ID: <042d2815-628c-e6b1-1eda-1e385dc26bcc@btinternet.com>
 by: Tony Flury - Wed, 19 Jan 2022 10:57 UTC

I am writing a C extension module for an AVL tree, and I am trying to
ensure reference counting is done correctly. I was having a problem with
the reference counting so I worked up this little POC of the problem,
and I hope someone can explain this.

Extension function :

static PyObject *_Node_test_ref_count(PyObject *self)
{
    printf("\nIncrementing ref count for self - just for the hell
of it\n");
    printf("\n before self has a ref count of %ld\n", Py_REFCNT(self));
    Py_INCREF(self);
    printf("\n after self has a ref count of %ld\n", Py_REFCNT(self));
    fflush(stdout);
    return self;
}

As you can see this function purely increments the reference count of
the instance.

/Note: I understand normally this would be the wrong this to do, but
this is a POC of the issue, not live code. In the live code I am
attaching a 2nd nodes to each other, and the live code therefore
increments the ref-count for both objects - so even if the Python code
deletes it's reference the reference count for the instance should still
be 1 in order to ensure it doesn't get garbage collected./

This function is exposed as the test_ref method.

This is the test case :

    def test_000_009_test_ref_count(self):
        node = _Node("Hello")
        self.assertEqual(sys.getrefcount(node), 2)
        node.test_ref()
        self.assertEqual(sys.getrefcount(node), 3)

The output of this test case is :

test_000_009_test_ref_count (__main__.TestNode) ...
Incrementing ref count for self - just for the hell of it

 before self has a ref count of 2

 after self has a ref count of 3
FAIL

======================================================================
FAIL: test_000_009_test_ref_count (__main__.TestNode)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/tony/Development/python/orderedtree/tests/test_orderedtree.py",
line 62, in test_000_009_test_ref_count
    self.assertEqual(sys.getrefcount(node), 3)
AssertionError: 2 != 3

So I understand why the first assert will be true - when the
sys.getrefcount() function is called the ref count is incremented
temporarily (as a borrowed reference), so there are now two references -
the 'node' variable, and the borrowed reference in the function call.

We then call the 'test_ref' method, and again that call causes a
borrowed reference (hence the ref count being 2 initially within the
method). The 'test_ref' method increments the reference of the instance
- as you can see from the output we now have a ref count of 3 - (that
count is the 'node' variable in the test case, the borrowed reference
due to the method call, and the artificial increment from the 'ref_test'
method).

When the 'ref_test' method exits I would expect the ref count of the
instance to now be 2 (one for the 'node' variable, and one as a result
of the artificial increment increment').

I would therefore expect the 2nd assertEqual in the test case to
succeed. - in this case the borrowed reference within sys.getfrefcount()
should cause the count to be 3.

As you see though that 2nd assertEqual fails - suggesting that the
refcount of 'node' is actually only 1 when the 'test_ref' method exits.

Can someone explain why the 'test_ref' method fails to change the
refcount of the 'node' instance.

devel / comp.lang.python / Puzzling behaviour of Py_IncRef

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor