Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[P12][P13] MetaLinkInstaller raises NodeNotFound when installing an object-centric permalink for a variable slot defined in a superclass #16548

Open
adri09070 opened this issue Apr 29, 2024 · 0 comments

Comments

@adri09070
Copy link
Contributor

Bug description
When installing an object-centric permalink on a variable slot, the method registerAndInstallPermaLink:forTarget: takes all nodes that access this slot and it installs the metalink on the equivalent nodes in the anonymous subclass of the object:

registerAndInstallPermaLink: aPermaLink forTarget: aSlotOrVar
	| nodes |
	(linksRegistry canReinstallPermaLink: aPermaLink)
		ifFalse: [ ^ self ].

	linksRegistry registerPermaLink: aPermaLink.

	nodes := (aSlotOrVar accessingNodesFor: aPermaLink persistenceType) asIdentitySet.
	aPermaLink targetObjectOrClass link: aPermaLink link toNodes: nodes

However, if the target variable slot has been defined by one of the superclasses of the object, it does not exclude the accessing nodes that are not in the object's class hierarchy (so: the nodes from methods that are in brother/cousin classes). As a result, it will try to find equivalent nodes in the anonymous subclass but these nodes do not exist so an exception NodeNotFound is raised.

To Reproduce

  1. open a playground,
  2. run obj := SindarinDebuggerTest new,
  3. Inspect the object obj,
  4. Click on the object-centric icon in the inspector toolbar (at the top, icon with colored circles),
  5. Click on "Break on state access",
  6. The exception is raised.

Expected behavior
No exception should be raised, the method registerAndInstallPermaLink:forTarget: should reject all nodes from methods that are not in the object's class hierarchy

Version information:

  • Pharo Version 12, but I wouldn't be surprised if the problem has been there since the beginning

Expected development cost
Easy fix, the analysis above was the hardest to do

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants