Bug 35386

Bug: 35386

Impact:

Critical

Product:

GemBuilder for Smalltalk/VW

Versions:

7.6.1, 7.6, 7.5, 7.4.1, 7.4, 7.3.3, 7.3.2, 7.3.1, 7.3, 7.2.2, 7.2.1, 7.2, 7.1.2, 7.1.1, 7.1, 7.0.2, 7.0.1, 7.0, 6.2, 6.1, 6.0, 5.2.3, 5.2.2, 5.2.1

Platform:

All

Fixed In:

8.0

Possible to lose modifications through concurrent operations

If multiple Smalltalk Processes concurrently manipulate the same replicate, it is possible for a change to that replicate to be lost. For this to happen, specific circumstances must be occur in a quite narrow time window.

Specific circumstances:

In most versions of GBS, if one Process modifies a replicate while another process is making the replicate into a stub, the modification can be lost. Replicates become stubs due to either an explicit request or as the result of server execution if the object has changed on the server and its fault policy is #lazy.

In a few versions of GBS, if one Process modifies a replicate while another Process is initiating server execution, the modification can be lost.

When using the GBS automatic dirty-marking feature in VA Smalltalk and VisualWorks 7.x, it is possible for GBS to make these failures impossible. In VisualWorks 5i, making automatic dirty-marking immune to these failures would slow execution down, so we do not anticipate ever fixing this problem in VisualWorks 5i.

All applications which manually mark objects dirty are vulnerable to this problem.

We recommend that all customers use VisualWorks 7.x or VA Smalltalk, and that that their applications use automatic dirty-marking. If you must use VisualWorks 5i or manual dirty-marking, the application must be very careful when accessing sessions and their replicates from more than one Smalltalk Process.

Workaround

No workaround