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

Pharo 7.0.2 - #findOriginClassOf: was sent to nil (when deleting many classes) #2831

Open
macta opened this Issue Mar 15, 2019 · 6 comments

Comments

Projects
None yet
2 participants
@macta
Copy link
Contributor

macta commented Mar 15, 2019

Since pharo 7.0.2, I've now started hitting this walkback when deleting 100 classes via a package (the classes are in pairs, and in 50 tags).

It looks like we don't handle the missing class very well.

This was never an issue in 7.0.1 - did somethng change?

UndefinedObject(Object)>>doesNotUnderstand: #findOriginClassOf:
UndefinedObject>>doesNotUnderstand: #findOriginClassOf:
CompiledMethod>>origin
ClyMethodChange>>handlesAnnouncement:
WeakAnnouncementSubscription>>handlesAnnouncement:
[ :each |
(each handlesAnnouncement: anAnnouncement)
ifTrue: [ s nextPut: each ] ] in [ :s |
subscriptions
do: [ :each |
(each handlesAnnouncement: anAnnouncement)
ifTrue: [ s nextPut: each ] ] ] in SubscriptionRegistry>>subscriptionsHandling: in Block: [ :each | ...
IdentitySet(Set)>>do:
[ :s |
subscriptions
do: [ :each |
(each handlesAnnouncement: anAnnouncement)
ifTrue: [ s nextPut: each ] ] ] in SubscriptionRegistry>>subscriptionsHandling: in Block: [ :s | ...
Array class(SequenceableCollection class)>>new:streamContents:
Array class(SequenceableCollection class)>>streamContents:
SubscriptionRegistry>>subscriptionsHandling:
[ interestedSubscriptions := self
subscriptionsHandling: anAnnouncement ] in SubscriptionRegistry>>deliver: in Block: [ interestedSubscriptions := self...
[ aBlock value ] in SubscriptionRegistry>>protected: in Block: [ aBlock value ]
[ caught := true.
self wait.
blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in Block: [ caught := true....
BlockClosure>>ensure:
Semaphore>>critical:
SubscriptionRegistry>>protected:
SubscriptionRegistry>>deliver:
SystemAnnouncer(Announcer)>>announce:
SystemAnnouncer>>announce:
SystemAnnouncer>>classTagRemoved:fromPackage:
RPackage>>basicRemoveTag:
[ :eachTag | self basicRemoveTag: eachTag ] in RPackage>>removeClassDefinitionName: in Block: [ :eachTag | self basicRemoveTag: eachTag ]
Set>>do:
RPackage>>removeClassDefinitionName:
RPackage>>removeClassNamed:
RPackageOrganizer>>fullyRemoveClassNamed:
RPackageOrganizer>>systemClassRemovedActionFrom:
WeakMessageSend>>value:
WeakMessageSend>>cull:

@macta

This comment has been minimized.

Copy link
Contributor Author

macta commented Mar 15, 2019

Closing all my system browsers and deleting my classes again seemed to fix it - but have never seen this before and have done it tons of times

@Ducasse

This comment has been minimized.

Copy link
Member

Ducasse commented Mar 16, 2019

Hi tim

Do you have a reproducible case?

@macta

This comment has been minimized.

Copy link
Contributor Author

macta commented Mar 16, 2019

I think I do - you need lots of classes in a project and then delete that project. I’ll report back later as I think my exercism project gives an easy repro case.

@macta

This comment has been minimized.

Copy link
Contributor Author

macta commented Mar 17, 2019

Hmmm - its not easily reproducible in a new image unfortunately.

I tried loading:

Metacello new 
 baseline: 'Exercism'; 
 repository: 'github://exercism/pharo-smalltalk:master/dev/src';
 load.

And then right click on the exercism "project-smalltalk" project in the iceberg repositores view, and then choose Metacello | Install baseline.... and finally type "dev" - that will load the project I was using, and crucially, there is an ExercismWIP package that has 50+ tags with classes in them.

This WIP project is what I have been deleting to test my generation of classes. Initially I thought just opening a few browsers on some of those classes and then deleting the WIP package might do it - however this doesn't cause this issue.

So I think, that it must entail having some browsers open on some of those WIP test cases, and then loading some branches - but even when I do a few branch loads I can't get it to fail.

I guess leave this open for a week (until April) and if it doesn't happen again, we can close it.

@macta

This comment has been minimized.

Copy link
Contributor Author

macta commented Mar 19, 2019

I've hit this again - with a different setup. While developing for Exercism, I create a branch for a new exercise. I then worked on that exercise (it was in the ExercismWIP-tournament package). When i got it working, I moved my exercise to Exercism-tournament. I then started working on something else, and realised that I was still on my tournament branch. So I switched branch to master (but opted not reload changes - so it acted like a stash). I then did a pull on origin, and chose to do the experimental merge. This worked ok, but I needed to revert my exercise changes (so they wouldn't be mixed in with my new piece of work). So I then did a reload package on Exercism (fine), but when I did a reload package on ExercismWIP I got the same error. Its the Calypso browsers holding on to my old exercise classes and not processing the updates from the load.

@macta

This comment has been minimized.

Copy link
Contributor Author

macta commented Mar 21, 2019

I hit this again, loading code from Exercism, which loaded another version of a class via http (and replaced my hello world test case that was currently visible in the browser). The browser seemed to have an old version of the class and was then triggering this error. Closing this browser, then cured the error.

So it seems like an easy'ish thing to create, but does require a bit of random interaction to achieve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.