Silvermark's Testmentor crashes with VASMalltalk 8.6.1

We migrated our project from version 8.6 to 8.6.1.

Everything work fine, except our gui regression tests with Silvermark's Testmentor. Every time, when the Testmentor throws an exception, an error in VASmalltalk is raised: Primitive failed in: Process>>#stackAtFrame:offset: due to Value out of range in argument 2.
 
This is caused by #EsImageStartUp class>>#outputWalkback:on:process: where since version 8.6.1 a timestamp is added to the walkback. But there is not only the timestamp new. No, there was a #ifTrue:ifFalse which checked a #isNil. This statement was changed to a #ifNil:ifNotNil Maybe this looks now real cool, but it do not work with the Testmentor.
So I changed the #ifNil:ifNotNil: into #ifTrue:ifFalse: and erverything works fine again.

Why reacts #ifNil:ifNotNil: in another way as #ifTrue:ifFalse: although semantically it should be the same.

Stack trace is attached.

Regards

Klaus

I noticed this error at 20.11.2014 (actually all runtime executables have this problem) and contacted Instantiations and they have a patch available at 02.12.2014. Case INST56768

Semantically it is the same - but the compiler introduced stack behaviour is different and that is critical if you actually work on that stack during this method - that's the answer John gave to me .... because I also looks only at the semantically difference.

Am Dienstag, 6. Januar 2015 14:09:35 UTC+1 schrieb Klaus Breker:

Why reacts #ifNil:ifNotNil: in another way as #ifTrue:ifFalse: although semantically it should be the same.

Wrong case number ... sorry, but the patch is included in the file ...

Thanks for your replies.

Am Dienstag, 6. Januar 2015 14:52:32 UTC+1 schrieb Joachim Tuchel:

The fact that ifNil: and friends are optimized doesn't really help in understanding what is really happening...

What I mean is that the VM does not execute the Smalltalk code of ifNil: , but uses a primitive for that. I am far from being an expert here, but I guess this means that ifNil: just doesn't show up on the stack as you'd expect it to...

Question to Instantiations: 

The error happens in a packaged runtime environment (in my case a GUI application) when an error is signaled and not catched - the system tries to write a walkback-information into a file and therefore works heavily on the stack of Smalltalk and as I understand the different approach changes the stack by itself and therefore breaks the method. That means during handling the first exception another exception is thrown ... and so on .... in my case the walkback.log is growing and growing and never stops until your harddisc may be actually full (but I've not reached that point :-))).

With that patch *my* problems are gone ...

Marten

Am Mittwoch, 7. Januar 2015 12:30:17 UTC+1 schrieb Joachim Tuchel:

Question to Marten:

What are the exact circumstances under which the error occurs?

There are some other problems with 8.6.1. If you build a GUI with WBPro and you use icons in your GUI - then the packaged application will perhaps not be able to load your icons, because during packaging of your new created application, several (newly introduced) sub-classes are considered to be removed - which are needed under Windows to load these icons ... you must add some build rules to include these classes. (Case INST56789)

Another problem is, that during packaging of a WBPro application the OLE subsystem may throw an exception. Reason is the OSICLRMetaHost class... fixed by Instantiation via case 56709 (13.11.14).


Perhaps actually this situation shows again, that a public available CASE-List would be a pretty good idea ... and it was mentioned at the VASmalltalkUserEvent in Stuttgart several years ago ....

According to yesterdays eMail this is now "case 57155"

Am Mittwoch, 7. Januar 2015 13:02:52 UTC+1 schrieb Marten Feldtmann:

There are some other problems with 8.6.1. If you build a GUI with WBPro and you use icons in your GUI - then the packaged application will perhaps not be able to load your icons, because during packaging of your new created application, several (newly introduced) sub-classes are considered to be removed - which are needed under Windows to load these icons ... you must add some build rules to include these classes. (Case INST56789)

Am Mittwoch, 7. Januar 2015 13:02:52 UTC+1 schrieb Marten Feldtmann:

Perhaps actually this situation shows again, that a public available CASE-List would be a pretty good idea ... and it was mentioned at the VASmalltalkUserEvent in Stuttgart several years ago ....