Smalltalk › Instantiations

Debug: Dump stack trace due to error 27 - EsPrimErrDNURecursion - doesNotUnderstand: is not understood

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Wayne Johnston

Debug: Dump stack trace due to error 27 - EsPrimErrDNURecursion - doesNotUnderstand: is not understood

Our headless server (VA 8.5.2) is suddenly sometimes hitting this, which we've never seen before. Does it mean "doesNotUnderstand: is not understood", which is hard to believe since I see it in Object in the packaged image? Or does it mean doesNotUnderstand: is sending a non-understood message, as "EsPrimErrDNURecursion" might imply? Not that I see anything missing from the packaged image in that method.

When this happens, the (Transcript) log file contains a fairly primitive stack trace, just one line per method, ending with a method of ours which is in the packaged image, but we don't know what method it was trying to call.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Richard Sargent

Re: Debug: Dump stack trace due to error 27 - EsPrimErrDNURecursion - doesNotUnderstand: is not understood

Administrator

On Monday, August 11, 2014 7:47:10 AM UTC-7, Wayne Johnston wrote:

Our headless server (VA 8.5.2) is suddenly sometimes hitting this, which we've never seen before. Does it mean "doesNotUnderstand: is not understood", which is hard to believe since I see it in Object in the packaged image? Or does it mean doesNotUnderstand: is sending a non-understood message, as "EsPrimErrDNURecursion" might imply? Not that I see anything missing from the packaged image in that method.

Do you have any classes / hierarchies which do not subclass from Object? (e.g., proxies, etc.) It is important that any such class have the DNU handler that's been defined to the VM (see Core class>>#registry).

Seth Berman

Re: Debug: Dump stack trace due to error 27 - EsPrimErrDNURecursion - doesNotUnderstand: is not understood

Hi Wayne,

I would agree with Richard about the possible culprit (I'm making an assumption that #doesNotUnderstand: did not get reduced out here).

The vm is processing the DNU handler and it goes to lookup the selector for the target object....but can't find it. So rather than trying it again, which would be pointless, this is the error code to say implicitly that there is a dnu recursion detected.

-- Seth

On Monday, August 11, 2014 12:01:06 PM UTC-4, Richard Sargent wrote:

On Monday, August 11, 2014 7:47:10 AM UTC-7, Wayne Johnston wrote:
Our headless server (VA 8.5.2) is suddenly sometimes hitting this, which we've never seen before. Does it mean "doesNotUnderstand: is not understood", which is hard to believe since I see it in Object in the packaged image? Or does it mean doesNotUnderstand: is sending a non-understood message, as "EsPrimErrDNURecursion" might imply? Not that I see anything missing from the packaged image in that method.

Do you have any classes / hierarchies which do not subclass from Object? (e.g., proxies, etc.) It is important that any such class have the DNU handler that's been defined to the VM (see Core class>>#registry).

Wayne Johnston

Re: Debug: Dump stack trace due to error 27 - EsPrimErrDNURecursion - doesNotUnderstand: is not understood

Thanks guys. I posted this before I realized I could reproduce it in a development image. Very weird stuff, I'll be contacting Instantiations support.

Wayne Johnston

Re: Debug: Dump stack trace due to error 27 - EsPrimErrDNURecursion - doesNotUnderstand: is not understood

Instantiations agreed it seemed like a corruption and was helping me. But I stumbled on the answer.

Just in case it was something in the class that tended to blow up which was corrupt, I thought I’d add an instance variable (and class variable and class instance variable just in case), then remove them. I didn’t know if that would recompile any corruptions out or not. Indeed, the problem still occurred.

HOWEVER, when I did that, the Transcript noted some methods that didn’t compile. I had removed an instance variable and these methods had still been referencing it without me realizing it. And I was still calling those methods. I’m guessing that the code setting the instVar was setting something haphazardly in memory.

Once I brought the instance variable back, all is fine.

Steven LaFavor

Re: Debug: Dump stack trace due to error 27 - EsPrimErrDNURecursion - doesNotUnderstand: is not understood

Here's a question for Instantiations - is there some sort of internal flag for a method that could be checked for a "method did not recompile" condition like this other than by forcing a recompilation of a method again? I know that when the method is recompiled, the Transcript shows the issue, but in the cases where that may have been missed, is there something that could be queried in the methodDictionary of a class? A compiledSuccessfully boolean that could be added to an instance of a compiled method possibly?

Thoughts?

*Steve*

Richard Sargent

Re: Debug: Dump stack trace due to error 27 - EsPrimErrDNURecursion - doesNotUnderstand: is not understood

Administrator

On Monday, August 18, 2014 8:14:36 AM UTC-7, Steven LaFavor wrote:

Here's a question for Instantiations - is there some sort of internal flag for a method that could be checked for a "method did not recompile" condition like this other than by forcing a recompilation of a method again? I know that when the method is recompiled, the Transcript shows the issue, but in the cases where that may have been missed, is there something that could be queried in the methodDictionary of a class? A compiledSuccessfully boolean that could be added to an instance of a compiled method possibly?

You mean something like CompiledMethod>>#doesNotCompile?