vmtrap

[Neil Morrison]

Me again,

We have recently transitioned from 9.1 to 13.0

Have been getting random vmtraps on occasion - never in the development tool

The vmtrap.log talks about a broken class - a VM corruption

Is there anything the vmtrap.img file can tell me?

Regards,

Neil

[Marcus Wagner]

Hi Neil,

a Vmtrap protocols a failure of the virtual machine while interpreting translated Smalltalk instruction (P Code). 

Failures protocolled here cover those which happen in circumstances not in reach of the language, most of lowest level origin (operating system, instructions, hardware, environment interactions), while interpreting instructions in a real environment under real stress. 

As being a result of the vm being unable to process the instructions you control (Smalltalk code) it is a last resort to trace such situations which are to be controlled intentionally by the VM, hence the product owner. 

Being part of the trade secrets of a concrete realisation of concepts published elsewhere in the beginnings (blue bock chapters of VM, e.g.), the vmtrap.img is intentionally saying you almost nothing but giving hints to its producer (now Instantions) about how the underlying system failed.

And now to become more precise: you wrote you get vmtraps but never in the development tool. 

There seems to be a contradiction to be clarified.

As I clearly stated, a vmtrap is a result of the failure of the vm, being busy in interpreting Smalltalk code in an image. 

As you dropped "development tool", this is one of these (the most prominent) images run in a VM, which seems not to be the cause of your problem.

You wrote about a broken class which could not be interpreted anymore by the VM. 

So the question is what failed: an image provided by you which could not be interpreted or an image coming from instantiations (the development image and then to investigate which version, as you change from 9.1 to 13).

And another important side effect: the bitness. The traditional 32 bit environment or the new 64 bit environment (brought to us as of 9.1).

If you run older stable Smalltalk code interacting with the environment and you switch the version of the runtime system, all hidden flaws tend to pop up. And also that the Pcode itself (the static content of images as well as the P code in the central repository) has to be maintained independent from its version. Such failures would crash EMSRV, but this is not Smalltalk code run in a VM, but run in an idependent process, if you do not use a standalone environment

For short: in lack of precise information there is no way look at this closer and give you hints from the outside. 

It is important to know what image in which runtime system caused a vmtrap.

PS: as an example i have ST code which runs perfectly in all available 32 bit versions, from 3.0 to 13, under 32 bit or 64 bit.

I inspect this code using the Envy Benchmark. The benchmark results (a trace of execution) is then subject to an inspection, a code execution or distribution, giving you a (hierarchically ordered) insight of what was run how often and its cost. 

This inspection fails with a VMTRAP but only under Windows, 64 bit, VAST Images, never in IBM images or 32 bit I did not check if it fails under Linux.

I suspect that a call from Smalltalk to the external world causes the failure and produces a VMTRAP. And this call is part of the tool in the development environment, not part of the vm, my code or even the virtual machine or runtime system.

The points is, it is not my code, its not even the data produced by the benchmark monitor, it is the interpration of the benchmark distribution which fails calling an API to the outer world (a DLL). I have no insight into to this code.

Back to your problem:

So precise information is important to solve the issue. Most of the time it is delicate to disclose the contributing underlying ST code.

To turn around, the VMTRAP is supporting detecting the cause having access to the VM source code. 

Its content is not disclosed to my knowledge.

In other words, a VMTRAP is geared for the producer (once OTI, then IBM and now Instantiations) of the VM, only.

The VMTRAP does not tell you much, except when you are twiddling yourself with low level details or primitves, and then giving you a hint what you made potentially wrongin your code. 

In the most common situations it helps the maintenance of the vm to trace what originating conflict causes the vm to stop providing its service.

So vmtrap is an important mean given to the support team to effectively provide help for customers.

Finally: to the hint of a broken class. this indicates me (as outsider) that (the internal bookkeeping of classes is broken and) interpreting the P Code became impossible.

There are few ways to corrupt internal memory in Smalltalk. Most of this is related to failures in APIs or primitives to the exernal world.

Sometimes it also related to memory corruption caused by not obeying the rules and governance of the runtime system and its garbage collection techniques.

I remember such ancient situations around thunks (calling 32 bit code out of Win 16 bit - the ancient Win32s - when ST was interpreted in a modern 32 bit runtime system living in a 16 bit world, Windows 3.x or Windows for Workgroups).

Now we had a major bitness change again, after ages.

Regards

Marcus

[Neil Morrison]

Thanks - didn't think the vmtrap file would be much use - had been wondering if Instantiations had a means to interpret them is all

Anyways, think we have got to the bottom of the issue - not a coding issue, more an environment issue

Stil trying to prove precisely as it may be useful for Instantiations to know

Thanks,

N