1. GemStone/S 64 Bit 3.5.8 Release Notes


GemStone/S 64 Bit™ 3.5.8 is a new version of the GemStone/S 64 Bit object server, including a number of feature enhancements and bug fixes.

These release notes describe changes between the previous version of GemStone/S 64 Bit, version 3.5.7, and version 3.5.8. If you are upgrading from a version prior to 3.5.7, review the Release Notes for each intermediate release to see the full set of changes.

The Installation Guide has not been updated for this release. For installation, upgrade and conversion instructions, use the Installation Guide for version 3.5.6 for the Mac, or 3.5.3 for other platforms.

Supported Platforms

Platforms for Version 3.5.8

GemStone/S 64 Bit version 3.5.8 is supported on the following platforms:

  • Red Hat Enterprise Linux Server and CentOS Linux 6.10, 7.9, and 8.5; Ubuntu 18.04 and 20.04
    GemStone performs testing on a mixture of Red Hat and CentOS servers; both are fully certified platforms. Any reference to Red Hat applies to both distributions.
  • Solaris 10 on x86
  • AIX 7.1 and 7.2
  • MacOS 11.1 (Big Sur) with Darwin 20.2.0 kernel, and MacOS 10.15.6 (Catalina) with Darwin 19.6.0 kernel, on x86
    Mac is supported for development only.

For more information, please refer to the GemStone/S 64 Bit Installation Guide for that platform.

GemBuilder for Smalltalk (GBS) Versions

GemStone/S 64 Bit version 3.5.8 requires GBS version 8.4 or later for VisualWorks Smalltalk, or version 5.4.5 or later for VAST Platform (VA Smalltalk).

The following versions of GBS are supported with GemStone/S 64 Bit version 3.5.8.

GBS version 8.5

VisualWorks 8.3.2


VisualWorks 8.3.2


  • Windows 10
  • RedHat ES/CentOS 8.5 and 7.9;
    Ubuntu 20.04 and 18.04
  • Windows 10
  • RedHat ES/CentOS 8.5 and 7.9;
    Ubuntu 20.04 and 18.04
GBS version 8.4

VisualWorks 8.3.2


VisualWorks 8.3.2


  • Windows 10
  • RedHat ES/CentOS 8.5 and 7.9;
    Ubuntu 20.04 and 18.04
  • Windows 10
  • RedHat ES/CentOS 8.5 and 7.9;
    Ubuntu 20.04 and 18.04
GBS version 5.4.6

VAST platform 10.0.2

VAST platform 9.2.2

VAST platform 8.6.3

  • Windows 10                     
  • Windows 10                    
  • Windows 10
GBS version 5.4.5

VAST platform

VAST platform

  • Windows 10                     
  • Windows 10

For more details on supported GBS and client Smalltalk platforms and requirements, see the GemBuilder for Smalltalk Installation Guide for that version of GBS.

VSD Version

The GemStone/S 64 Bit v3.5.8 distribution includes VSD version 5.5.3. The previous version of GemStone/S 64 Bit, v3.5.7, included VSD v5.5.2. VSD 5.5.3 includes improved searching, bug fixes, and updates to the help system.

VSD v5.5.3 is included with the GemStone distribution, and can also be downloaded as a separate product. For details or to download, go to https://gemtalksystems.com/vsd/.

Changes in this release

Updated Library Versions

The version of OpenSSL has been updated to 1.1.1m

The version of Kerberos has been updated to 1.19.2

Restore from Backup specifying SystemUser password

GemStone backups include all objects in the repository, which include UserProfiles such as SystemUser and DataCurator, and the passwords for these accounts at the time the backup was made. These passwords, of course, must be known to GemStone Administrators, but should be kept private and changed regularly for system security.

In previous releases, this added a requirement that along with GemStone backups, the administrative passwords that were valid at the time of that particular backup had to be recorded. Otherwise, while the backup could be restored if necessary, it was possible that administrative accounts could not log in.

Now, you may restore secure or unsecured backups and at the same time, specify a new password for SystemUser, using Repository methods with the new newSystemUserPassword: keyword. This allows you to restore a backup so the restored repository will have SystemUser’s password set to the argument password. SystemUser can login, and update other passwords as needed to allow complete use of the restored repository.

Security Implications of this change

If your application contains sensitive data that should not be visible to unauthorized individuals, there are several administrative requirements that become more immediately visible with this feature. These requirements are not new; in previous releases plain text data may be visible within the bytes of a non-secured backups.

  • All backups should be secured, using Repository>>secureFullBackup* methods; or access to/file permissions of backup files must be strictly controlled. Note that, while not officially supported, a backup from a previous release of GemStone can be restored into v3.6.3.
  • Only GemStone userProfiles for users with full authorization to see all data in the repository should be granted FileControl privilege. This privilege allows you to make programmatic backups as well as restore and perform transaction log operations.

New Restore Methods

The following instance methods have been added to Repository, which are variants of existing methods with the additional keyword newSystemUserPassword:.


Previously, the simple secure backup method accepting a passphrase file did not exist; this method, and the variation with the additional keyword, have also been added:


The argument to the newSystemUserPassword: keyword is a String meeting the same restrictions as to the password: method. Following the restore, login as SystemUser requires this password string.

Post-restore login as SystemUser

When restoring using the methods that allow you to specify a new SystemUser password, you must be logged in as SystemUser. This restores the objects in the backup; but the new SystemUser password is saved in encrypted form in the root page state of the repository. The restore itself does not update SystemUser’s UserProfile object.

It is strongly recommended to log in again as SystemUser after the commitRestore (if you are in full transaction logging mode), or after the restore is complete (in partial logging mode). This login will cause the SystemUser password to be updated in SystemUser’s UserProfile.

  • If you make a programmatic backup before the SystemUser login (post-commitRestore), the backup will not contain the password defined by newSystemUserPassword:; since backup backs up the UserProfile data. If this second backup is restored (without using newSystemUserPassword:) the SystemUser password will be the one in the original backup, not the one specified by the first restore using newSystemUserPassword:.
  • It is disallowed to explicitly set SystemUser’s password (using e.g. password:), when logged in as a user other than SystemUser, after a restore specifying a new SystemUser password but without any later (post-commitRestore) logins as SystemUser.

Shutting down the stone does not affect the SystemUser password state in the root page; after restart, the SystemUser password remains as set by newSystemUserPassword:.


Added methods

The following method has been added:

UserProfile >> isSystemUserProfile

Privileges Changes

OtherPassword split with ReadOtherUserProfile

Finding out any information about another user’s UserProfile, such as the lastLoginTime or authenticationScheme, previously required OtherPassword privilege. This privlege also allowed modifying another users’s UserProfile.

To allow reading another user’s UserProfile, but not allow modifcation, a new privilege, ReadOtherUserProfile, has been added. A UserProfile with this privilege can read some information for other UserProfiles, but cannot make changes.

A UserProfile with OtherPassword has implicitly also ReadOtherUserProfile, so there is no need to grant this additional privilege to users with OtherPassword.

The following methods can be executed by a UserProfile with OtherPassword, ReadOtherUserProfile, or both privileges:

UserProfile >> activeUserIdLimit
UserProfile >> authenticationScheme
UserProfile >> hasLoginLogging
UserProfile >> isReadOnly
UserProfile >> lastLoginTime
UserProfile >> lastPasswordChange
UserProfile >> ldapBaseDn
UserProfile >> ldapSearchFilterDn
UserProfile >> loginsAllowedBeforeExpiration
UserProfile >> passwordAgeLimit
UserProfile >> passwordAgeWarning
UserProfile >> staleAccountAgeLimit
UserProfile >> userIdAlias
UserProfile >> passwordNeverExpires

Placeholder for MigrateObjects privilege

This privilege is present in v3.5.8, but not used.

GemStone-specific SUnit classes now renamed and in image

The classes GSTestCase, GSTestResult, and GSTestSuite, which have been distributed in the $GEMSTONE/examples/testing directory, have been renamed to GsTestCase, GsTestResult, and GsTestSuite, and are now in Globals in the image.

These classes provide additional protocol and GemStone-specific behavior to the existing SUnit framework. These classes are also used internally at GemTalk for product testing.

The distribution no longer includes the directory $GEMSTONE/examples/testing.


The class NonPersistentArray has also been added to the image; this is used by the GsTest framework, but is available for general use. It is a subclass of Array with the class option #instancesNonPersistent.

Changes from examples/testing

In addition to the class name change, the GemStone SUnit classes now included in the image include bug fixes from the versions included in $GEMSTONE/examples/testing in previous releases.

GsTestResult did not distinguish errors and failures

GsTestResult treated errors and failures as the same, which led to miscounting of errors and of failures. SUnit supports defects, which includes both errors and failures.

GsTestResult now tracks defects, as well as supporting the superclass errors and failures. The instance variable defects has been added to GsTestResult.

Note that the TestCase >> defects returns results sorted with all errors followed by all failures, while GsTestCase >> defects returns both errors and failures in order of occurrence.

The methods for logging failures has been corrected; the methods:

GsTestResult >> logFailure: aTestCase
GsTestResult >> failureLogFile

have been removed, and are replaced by new methods:

GsTestResult >> logDefect: aTestCase
GsTestResult >> defectLogFile

And these methods now write to SUnitDefects.log, rather than SUnitFailures.log

NonCoreTestCase and CoreTestCase not in image

The classes NonCoreTestCase and CoreTestCase have not been included in the GemStone kernel and the files are no longer distributed; these classes provide no particular value outside GemTalk internal testing.

GsTestResult inherited methods failed due to optimization

Instances of GsTestResult store printStrings of the GsTestCase instance run, rather than the instances themselves. This is more space efficient, but sending methods such as isError: to these objects returned incorrect results (always false).

The following methods, inherited from TestResult, are now disallowed for GsTestResult:


Removed methods

The following private methods have been removed:

Repository >> _primRestoreSecureBackups:scavPercentFree:
Repository >> _restoreBackups:scavPercentFree:bufSize:
UserProfile >> _validateUserProfileAccess

Added Error

The following error as been added, as part of the changes for bug 49715, described here.


An invalid tranlog record was received by the Stone.

Cache statistics changes

The following cache statistic has been added, as part of the changes for bug #49771, described here.

ExtentGrowFailedTotal (Stn)

Number of times an attempt to grow an extent failed.

Bugs Fixed

The following bugs in v3.5.7 are fixed in v3.5.8.

Object >> trackRead SEGV if object not committed

Object >> trackRead was added in v3.5.7 as part of the Object Read Tracking feature. If this method was sent to an uncommitted object, it resulted in a Gem crash with SEGV. (#49679)

Invalid record may be written to tranlog

Under some conditions, a Gem may attempt to write an invalid record kind 0; in the observed case, it should have been a BEGIN_DATA. Now, if such a case occurs, the Gem will get a fatal error (see GS_ERR_INVALID_TRANLOG_RECORD / 4021), and the data is not written to the tranlog. (#49715)

Issue with incremental tranlogging

A case was observed in which an entry in an NSC was not recorded in the transaction log when STN_TRAN_INCREMENTAL_LOGGING=true. (#49713)

Multi-threaded operations could use up all available process slots

When a multi-threaded operation such as markForCollection was requested with more threads than currently available process slots in the repository, previously the operation executed with as many threads as available process slots. This prevented other sessions from logging in, including stopstone. In addition, if the multi-threaded operation was expected to run with a large number of threads but only a small number of slots was available, it would run with those few threads, unexpectedly taking much longer to complete. (#49611)

Now, if there are not enough process slots available, the requested operation is executed with half as many threads as requested.

If this is still more than is available, an error is reported, allowing you to determine the reason for unavailable slots and correct the problem, or retry with a smaller number of threads.

SecurityErrors during upgrade in some GsObjectSecurityPolicies configurations

When upgrading from a version earlier than 3.5, if the GemStone base classes in the originating repository have an unusual distribution of classes and methods over the GsObjectSecurityPolicies, there may be security errors in upgradeImage, when CodeLibrarian performs the recompile of methods. (#49807)

GsDevKit upgrade bugs fixed

There were bugs in the code to upgrade GsDevKit (issues 15, 16, 21 and 23 on the github project). These fixes are included in the distribution in $GEMSTONE/examples/seaside/bin/GsDevKit_upgrade.gs. (#49795, 48510)


With the settings:


On stone startup, the SPC Monitor crashes with a SIGFPE (divide by zero). (#49737)

Native code errors in some cases using Array constructors {}

For some uses of the {} Array constructor syntax using nested blocks, with native code enabled, the Gem could encounter a SEGV or endless loop in methodLookupCache. (#49712)

Strings with µ/181 and ÿ/255 do not convert to uppercase correctly

The characters µ/code point 181 and ÿ/code point 255 have uppercase forms that are outside of the range of a Single-byte String. Sending asUppercase to a single-byte String containing either of these characters did not convert to a DoubleByteString, and resulted in a single-byte String containing the wrong upper case form. (#49741)

Handling of remote caches that failed startup

When a remote cache fails to start, the messages were misleading, and the retry logic incorrectly attempted retrying the fork. (#49718)

After failed commit due to RC conflicts, commit allowed without abort

If a commit fails due to RC conflicts, an abort should be done before a subsequent attempt to commit. This abort was not required, so a commit was allowed, which could bypass correct transactional behavior, since the commit was based on the view with partial updates from the RC replay. (#49777)

Extent grow cache statistics issues

The following stone cache statistics were not updated in some cases of grows initiated internally. The affected statistics are:


The statistic ExtentGrowFailedTotal has been added, to track extent grow failures; see ExtentGrowFailedTotal (Stn).


Epoch garbage collection failure may leave Admin GcGem in transaction

While Epoch GC runs, the AdminGem sets itself to be in automatic transaction mode. If Epoch fails to start, for example if there are not enough available process slots in the shared page cache, it did not correctly reset its transaction mode to #manualBegin, and thus remained in transaction. (#49657)

In comma-decimal point locale, ScaledDecimal literals did not parse

Locale can be used in GemStone to specify to use the comma as the decimal points, for fromString: and printing, but does not affect compiler parsing. ScaledDecimal literal syntax (using a period decimal point and s, such as 3.45s6) did not parse in a comma Locale. (#49822)

Crash if committed FFI structures are faulted and lose C data

There are cases in which CByteArrays and CPointers that used by FFI can be committed, faulted out, and lose C data when faulted in, causing the Gem to crash. (#49769). The changes in this release are to avoid the crash; the underlying bug condition remains.

.topazini could silently clear -X arguments for X509 login

By default, topaz automatically reads a existing .topazini file on startup. If the .topazini sets any of the standard login parameters (gemstone, username, etc.), it clears any X509 login parameters, including those passed in via the topaz command line. This design is intended to avoid mixing sets of login parameters

Now, a warning is printed if command line -X arguments are cleared by a .topazini setting. (#49761)

Extreme log growth attempting to printing stack if stack corrupted

Using kill -USR1 to print stacks to the process log file, in some case where the stack is corrupted, it may have entered a loop printing [ incomplete frame, send in progress ] to the log file, potentially filling up the disk space. (#49655)

Error during GciExecute from UserAction may prevent further interrupt servicing

If an error occurs during a GciExecute* operation when invoked from a UserAction, the VM may be left in a state such that no further interrupts are serviced, such as AlmostOutOfMemory, sigAbort, etc. (#49699)

GciTsObjInfo.access could return undocumented value

This field was documented to return a value in the range 0..2, but could in fact return other values. (#49762)