Dubious assignment to be a check in hv_cli_and.c #14
Comments
svenil
changed the title
|
Is it supposed to be |
|
How to get a reference to this class: Woah, that is more complicated than I had expected. |
|
Yeah, it's definitely wrong. |
|
This |
|
I could test it by accessing the low level classifier. It is available at hpy().View.hv.cli_and |
|
I can see you accessed the low level classifier too in a previous comment where you used the user defined classifier too, I didn't understand it or read it well enough right away. Mine was an alternative that was arguably easier to do. |
Yeah. Like, does the abstractions above invoke nodetuple_richcompare? I mean, if not, we could just test the low-level, or, we could test both high-level and low-level. |
|
I find that it is called but I can not produce an error. It is used when partitioning a large enough set with the and classifier. But gdb gives strange results. The richcompare is called with the same results each time, presumably from the dict lookup when there is hash collisions, but why is it getting the same arguments each time? Is it something wrong with gdb interaction? |
|
Woah Ok, a broken richcompare that is actively used but doesn't break the entire system... is interesting. I'm looking into it. |
|
Ah, I see. The hash "collision" is because the tuple values are the same, and our hash function has been good enough to avoid a collision when the tuple values are not the same. The bug was a false positive during a richcompare when the tuple are not the same, but in this case, richcompare would not be called if the hash values are different. There wouldn't be a way to trigger the bug unless we can generate a hash collision for different tuple values. Why is it getting the same arguments each time... probably because we aren't leaking memory and the tuple is recreated and destroyed again and again in Btw, the object that is being classified is |
Answer to self: Clodo, this is classifying during print so the set's printing classifer is still clodo. |
class AndClassifier(Classifier):
[...]
def get_kind(self, k):
ks = []
for ki, ci in zip(k, self.args):
ks.append(ci.get_kind(ki))
return self.mod.UniSet.fam_And._cons(ks)class Classifier:
[...]
def partition(self, iterable):
items = []
for k, v in self.partition_cli(iterable):
k = self.get_kind(k)
v = self.mod.Use.idset(v, er=self.er)
items.append((k, v))
return items
def partition_cli(self, a):
ep = self.call_with_referrers(
a,
self.cli.epartition)
return [(k, ep[k]) for k in ep.get_domain()]Yeah, I see the NodeTuple is iterated through and used to create a list, so I don't think at the high level there is any use of NodeTuple, after the classification. During classification the NodeTuple is only used as keys to the dict, which would be somewhat hard to make a hash collision to hit this bug. I guess a test at the low level is the way to go then. (Will do later) |
This assignment that will be a check is dubious. It is the same for the two cases. Suggest to fix and also have a test case that catches it, if possible. Does the code in
nodetuple_richcomparework as intended? I don't understand it after these years.hv_cli_and.c, lines 235-236
The text was updated successfully, but these errors were encountered: