Walkbacks resulting from destroyed widgets

[jtzecher]

About 30% of our recent production walkbacks seem to point to a root cause of a destroyed widget being the receiver of a callback. In going though the plethera of walkbacks (usually some form of UndefinedObject not understanding one method or another), the common point I was able to trace back to was the "#callHandlers: with:" method implemented in OSWidget in the PlatformWidgetsFramework sub application.

I thought that if I blocked callbacks to destroyed widgets, that should make my problems go away. I could not think of a valid reason why a callback would need to be executed on a widget that had been destroyed.

So, at the beginning of OsWidget>>#callHandlers: with: , I inserted this line:
owner isDestroyed ifTrue: [ ^self ].

Logic seemed to indicate that if you tested for the destruction of the receiver of the perform of the callback, you would successfully prevent resulting walkbacks. Empirical evidence collected since we moved this change into production indicates a flaw in the logic. Numerous examples of walkbacks have come back showing that the #callHandlers:with: method was executed passing the perform: handlers with:data to owner. And in the very next method, you could see that the label of owner was coming back with "*destroyed".

I am unsure of the flaw in my reasoning. I know there must be a flaw or I would have achieved the desired result.

I am considering changing the test to:
(self isDestroyed or: [owner isDestroyed]) ifTrue: [ ^self ].

I am considering this even though I am "sure" that owner should be the one being tested.

I am also considering adding the line
CwAppContext default asyncExecInUI: [].

I was thinking of adding this right before the test for #isDestroyed. Yes, I would do that with an empty block. I have seem some cases in the base code where this technique was occasionally used and it was an effective tool in helping rid us of the "Invalid operation during callback" walkbacks that plagued us a few years ago.

I have also scoured the old google group for vasmalltalk and the only relevant post I found was this one:
http://groups.google.com/group/ibm.soft ... dd708d334a

This seems to also point to using the asynExecInUI: method. The difference is that you are looking for specific callbacks and applying it to the entire block within. That would be difficult (impossible?) to apply here since there are potentially hundreds of cases of different callbacks. While it would be clear to identifiy which callbacks are failing, it would be more of a challenge to identify the callbacks that should come "first".

Any thoughts on the subject would be welcome.

[jtzecher]

I have been experimenting further with this code and the results have been underwhelming.

When I put the "self isDestroyed or: [owner isDestroyed]" code into the method, I found that it was still falling through. The most annoying thing is that I can only see this in walkbacks since I have not been able to come up with a reproducable script that will generate the walkback when I'm trying to watch it.

At any rate, questions I have:
1. Is it possible for a widget to say it is *destroyed* in the walkback when it is not actually destroyed?

2. Is it possible for a widget to be destroyed but return false when asked #isDestroyed?

3. What is the reason that the owner of the OsWidget is a BlockContextTemplate instead of a widget when you're using the CwPrompter? That one caused some problems in other areas. Easily solved by teaching Object to return false when asked #isDestroyed.

Please feel free to chime in. Answers to one or more of these questions would be welcome. Also welcome would be anything stating that my questions have me barking up the wrong tree and I should be doing.....

[solveig]

Hi,

I have been trying to look into this, but I need more information to make any progress. Could you open a case and send one of your walkbacks?

Thanks,
Solveig

[Michael Keppler]

We often experience similar issues, especially during automated GUI testing (where chances are much higher to run into such walkbacks, due to the much higher frequency of user input). Until now the only thing we have been able to do was to add a guard at the beginning of the callback routine which would check the widget state.

About your question whether or not a widget might be destroyed in the next method call, although it was not destroyed in the previous method call: We have discussed the same topic in our team and came to no conclusion. But we added another twist to this discussion: When the walkback is written to disk, this takes some time. Might it happen that the state of the widget changes either during that writing process or between the walkback happening and it being written? Sometimes that would be a good explanation for walkbacks which really can't be explained by inspecting the related methods.

[solveig]

Hi Michael,

Could you open a case by e-mailing to vast-support@instantiations.com and sent a walkback?

Thanks,
Solveig

[rjs]

We often experience similar issues, especially during automated GUI testing (where chances are much higher to run into such walkbacks, due to the much higher frequency of user input). Until now the only thing we have been able to do was to add a guard at the beginning of the callback routine which would check the widget state.

About your question whether or not a widget might be destroyed in the next method call, although it was not destroyed in the previous method call: We have discussed the same topic in our team and came to no conclusion. But we added another twist to this discussion: When the walkback is written to disk, this takes some time. Might it happen that the state of the widget changes either during that writing process or between the walkback happening and it being written? Sometimes that would be a good explanation for walkbacks which really can't be explained by inspecting the related methods.

One of the nastiest things to figure out under Windows is hidden asynchronous behaviours. Unless you are a well and truly experienced Windows developer, you can easily miss the distinction between Send and Post Windows messages. One of them sends and waits, while the other doesn't. I have investigated some of these crashes over the years, and found that in the low-level Smalltalk GUI code you sometimes miss the asynchronous aspect because the code hides it from you. It seems that when this happens, there is the opportunity for other Windows events to be processed, including the close functionality.

[jtzecher]

I just emailed the address you provided to open a case on this subject. Thank you for your interest. I hope that you can make something out of the walkbacks.

[solveig]

Joel,

We received your e-mail and have opened case 46925. Thanks. We will review the walkbacks and respond by e-mail.

Regards,
Solveig

[Ralf]

Hello,

is any solution in sight?

We have the same problem more and more. But I can not even see in the walkback.log, where the error come from. The only information I have is, the user has 3-4 windows open to work with the program. So, after 10 minutes the user will close a window and get the error.

A little information to me would be nice.

Best regards

Ralf

walkback.log

(4.8 KiB) Downloaded 25 times