1. GemStone/S 64 Bit 3.4.2 Release Notes


GemStone/S 64 Bitâ„¢ 3.4.2 is a new version of the GemStone/S 64 Bit object server. This release includes a number of new features and bug fixes. We recommend everyone using or planning to use GemStone/S 64 Bit upgrade to this new version.

These release notes describe changes between the previous version of GemStone/S 64 Bit, version 3.4.1, and version 3.4.2. If you are upgrading from a version prior to 3.4.1, review the release notes for each intermediate release to see the full set of changes. Particularly note that there were many changes in v3.4, including the requirement for updated keyfiles and GBS upgrade.

The Installation Guide has not been updated for this release. For installation, upgrade and conversion instructions, use the Installation Guide for version 3.4.

Supported Platforms

Platforms for Version 3.4.2

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

  • Red Hat Enterprise Linux Server 6.9 and 7.4, and
    Ubuntu 14.04 and 16.04, and SUSE Linux Enterprise 12, on x86.
    Testing has been done on some earlier Red Hat Enterprise Linux Server 6.x and 7.x versions with the latest security patches.
  • Solaris 10 and 11.3 on x86
  • AIX 6.1, 7.1, and 7.2
  • OS X 10.11.2 (El Capitan) with Darwin 15.2.0 kernel, and
    OS X 10.13.2 (High Sierra), with Darwin 17.3.0 kernel, on x86
    (Mac is supported for development only)

For more information and detailed requirements for each supported platforms, please refer to the GemStone/S 64 Bit v3.4 Installation Guide for that platform.

GemBuilder for Smalltalk (GBS) Versions

GemStone/S 64 Bit version 3.4.2 requires GBS version 8.3 or later for VisualWorks Smalltalk, or version 5.4.4 or later for VA Smalltalk.

The following versions of GBS are supported with GemStone/S 64 Bit version 3.4.2:

GBS version 8.3


32-bit and 64-bit





  • Windows 10 and Windows 7
  • RedHat ES 6.9 and 7.4; Ubuntu 14.04 and 16.04
  • Windows 10 and Windows 7
  • RedHat ES 6.9 and 7.4; Ubuntu 14.04 and 16.04
  • Windows 10
  • RedHat ES 6.9 and 7.4
GBS version 5.4.4

VA Smalltalk

  • Windows 10
  • Windows 8.1, Professional or above
  • Windows 2008 R2
  • Windows 7, Professional or above

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.4 distribution includes VSD version 5.3.1; this is the same version as was distributed with the previous GemStone/S 64 Bit, v3.4.1.

Changes in this release

Community and Web Edition licencing for GemBuilder for Smalltalk

The GemStone/S 64 Bit Community and Web Edition licensing now also include licencing for GemBuilder for Smalltalk (GBS). This allows free for commercial use, in production as well as development, for GBS.

The Community Edition license for GemBuilder applies to all GemBuilder client platforms, with Community Edition GemStone/S 64 Bit on Linux and Macintosh.

The Starter Community and Web Edition keyfile that is included in the GemStone/S 64 Bit distribution for Linux and Macintosh now allows GBS logins.

Added Support for AIX 7.2

This release adds support for AIX 7.2, which was verified on POWER7.

Updated library versions

The version of LZ4 has been updated to v1.8.2.

The version of OpenSSL has been updated to 1.1.0h.

The version of Kerberos has been updated to 1.16.1.

GemStone Banners now include UTC offset with timestamp

To increase the clarity of the timestamps in GemStone process header, the UTC offset has been added after the time.

For example:

DATE: 07/11/2018 10:53:31 PDT  (UTC +7:00) 

Initial session transaction mode

When a new session is logged in, historically it is always started in #autoBegin transaction mode and must be manually changed into another mode, if desired.

Now, you may configure the repository to start sessions in other modes.


Transaction mode of a session immediately after login. Value must be one of the GemStone transaction modes: autoBegin, manualBegin, or transactionless.

Runtime equivalent: #StnGemInitialTransactionMode (may only be set by

Default: autoBegin

Allow commit to proceed with Non-Persistent objects

If any of the objects being added or updated by a commit include a reference to an instance of a class with the option instancesNonPersistent, such as a Semaphore, commit will signal a TransactionError, to avoid committing an object with missing data or a nil reference. However, there are cases, notably for committing error stacks within the Seaside framework, where the specific non-persitent object is not important and there is no need to prevent the commit.

Now, if you set the runtime configuration option GemCommitStubsForNpObjects, the commit will commit a string in place of any non-persistent objects, rather than erroring.


Runtime-only config option for the gem, enabled by:

System gemConfigurationAt: #GemCommitStubsForNpObjects put: true

If true, an invariant String will be committed in place of an instance of a class which has the instancesNonPersistent option, instead of signalling TransactionError 2407.

Hot standby related changes

Replay of hot standby could lag with high rate of small tranlogs

When a hot standby system has a master repository that produces small tranlogs at a rapid rate, the replay into the slave system could fall behind. (#47566)

The transfer rate in this situation has been improved in several ways:

  • Reduced sleep time on socket EWOULDBLOCK.
  • Larger data socket send/receive buffer sizes.
  • Configurable flush interval in the logreceiver (described in more detail below).

logreceiver flush interval now configurable

The startlogreceiver utlity now accepts the -f <seconds> argument, configuring the flush interval for the logreciver to flush. The default is 10 seconds.

Previously, the flushing interval was always 2 seconds, which could reduce performance depending on the underlying disk performance, number and size of files.

-f <seconds> Interval in seconds at which the logreceiver flushes the tranlog file.
0 means flush as often as possible (caution: this may be very slow).
-1 disables flushing (file is flushed only when closed).
default: 10 seconds

Reduced printouts in logsender and logreceiver logs

Some log messages are now only printed to the logsender and logreceiver logs when the -d option is used, to reduce noise in the logs under normal operation.

logsender and logreceiver stats for block ID

Currently, the logsender and logreceiver can record, in statmonitor data, the only the tranlog file being processed. Now the block ID is recorded in SessionStat00 in logsender, and SessionStat23 in logreceiver.

Retrieving GemStone version from incompatible backup files

In the report created by copydbf -i on a backup file, the GemStone version that made the backup file is included.

However, if using copydbf -i on a backup file that was created by a different version of GemStone, and there are incompatibilties between the GemStone version of copydbf and the GemStone version used to generated the backup, copydbf did not handle the incompatibilities correctly.

In extreme cases, such as 3.4.x copydbf against a 2.4.x backup, the copydbf could SEGV with a log record swizzle error. More commonly, it reported an unhelpful error such as "expected compatibility level = 850, found 256".

Now, copydbf -i against a backup generated by an incompatible version of GemStone will include information about the version information if that is available. Version information is avilable for backups created from3.1.x and 3.2.x, but not from 3.3.x.

Additional control over temporary object memory subspace sizing

POM area scaling

The size of the POM Generation memory space can be set explicitly using the configuration parameter GEM_TEMPOBJ_POMGEN_SIZE, but is normally derived from the GEM_TEMPOBJ_CACHE_SIZE setting.

Previously, the calculation of the default was linear, setting the POM gen space to about 0.8 times (80%) of the TOC size. For very large temporary object caches, this is larger than is useful. Now, the multipler used is based on the size of the TOC, using interpolation on the line defined by these values::

TOC size


<= 200MB











This configuration parameter has been added to control the size of the PERM Generational memory space.

If the configuration value is zero the Perm generation is sized at 10% of CFG_GEM_TEMPOBJ_CACHE_SIZE up to a maximum of 30MB.

Default units K Bytes, suffixes KB, MB, GB may be used to specify units.

Default: 0

min: 200KB

max: 100MB

DSA now supported for signing secure backups

Secure backups are always signed, and are optionally encrypted, with signing and encryption using separate keys.

Now, DSA (Digital Signature Algorithm) keys are supported for signing a secure backup, as well as RSA keys. Only RSA keys are supported for encryption.

Scripts have been added under $GEMSTONE/examples/openssl to create DSA keys and cert files:


and example DSA cert and key files, also under $GEMSTONE/examples/openssl:


Changes in GCI

Added functions

The following functions have been added:

(int64) GciFetchUtf8Bytes__(
    OopType aString,
    int64 startIndex,
    ByteType *buf,
    int64 bufSize,
    OopType *utf8String,
    int flags,
    int64 maxConvert
(void) GciNbExecuteFromContextDbg_(
    OopType source,
    OopType contextObject,
    OopType symbolList,
    int flags,
    ushort environmentId

This is a non-blocking variant of GciExecuteFromContextDbg_().

flags for GciFetchUtf8Bytes_

These flags now include mneumonics:

GCI_UTF8_FetchNormal = 0,
GCI_UTF8_FilterIllegalCodePoints = 0x1,  /* not yet implemented*/
GCI_UTF8_NoError     = 0x2   /* return  message instead of signalling Exception*/
	} GciFetchUtf8Flags ;

Bugs Fixed

GCI Execute issues with UTF8 source containing code points greater than 255

GciExecute(), GciTsExecute(), and their variants did not work correctly with UTF8 source arguments that have code points greater than 255 (#47634)

GciTsLogin() crashes if host user and password are not provided

If the arguments for hostuser and hostpassword are not provided, executing GciTsLogin() may SEGV. (#47640)

Bug Fixes

LostOT handling issue

If a lostOt is deferred for certain reasons (blocked on a queue on the Stone or in the run queue), lostOt handling is deferred by an entire STN_GEM_ABORT_TIMEOUT / StnMntGemAbortTimeout interval, rather than by a fraction of a second. (#47329)

Stone memory leak in commit record bitmap caching

There was a slow C heap memory leak in the handling of bitmap caching for commit records. (#47646).

NonTranloggedGlobals can cause tranlog restore to fail

Under certain sequences of operations, when using NonTranloggedGlobals when the oopHighWaterMark is increasing, the oopHighWaterMark is not updated corrrectly. This does not cause the restoreFromLogs to fail, however, the stone cannot subsequently start up. (#47679)

Nested Transaction can create references to non existent objects

There is a sequence of processing within a nested transaction that has the ability to create a committed reference to an object that does not exist.

This involves a nested transaction followed by a failed commit of the outer transaction; then an abort and another commit. The problem is related to objects that were not correctly sorted between the closures of the inner and outer commits, such that state was not correctly handled by the abort. (#47659)

beginNestedTransaction did not handle instancesNonPersistent correctly

If the closure of a nestedBeginTransaction contained instances of classes with the option instancesNonPersistent, or other instances that were immune to rollback on abort, these objects were incorrectly being added to the closure of the nested transaction. This cause the later commit to the outer transaction to fail with error 2407 , attempt to commit a not committable object. (#47584)

Backups and tranlog numbering immediately after using /dev/null

If you run with tranlogs set to /dev/null, no tranlogs are generated. When you restart with tranlogs set to a normal directory, the sequence of tranlogs that is generated should begin with tranlog1.dbf, but in some cases it was starting with tranlog0.dbf. (#47636)

A backup taken when the current tranlog is tranlog0.dbf cannot be restored.

listInstancesInPageOrder:toFile: reports out of memory

When running listInstancesInPageOrder:toFile:, and there are no instances of the given class, it signalled an AlmostOutOfMemory error. (#47583)

Debugger single-stepping could get stuck

When single stepping through code in a debugger, it was possible for stepping to get stuck and be unable to advance. (#47314)

GsHostProcess file descriptor leak

GsHostProcess finalization of in-memory instances did not properly close its three pipes. (#47630)

Restore from backup with missing or corrupted objects

In 3.4 and earlier, if a backup file has corruption which prevents certain objects from being restored, the restore would terminate with a non-fatal error depending on the specific problem, and the backup file could not be restored. In v3.4.1, this was changed, such that restore would continue to complete the restore of backup and tranlogs and allow commitRestore.

In v3.4.2, there has been further refinement in the handling of this scenario. Now, while the backup continues, on completion, the restore reports a new fatal error, BKUP_ERR_RESTORE_FAILURE/4152, and commitRestore is disallowed.

Added method commitRestoreWithLostData

To commit the restored backup, instead of commitRestore, you must invoke the new method Repository >> commitRestoreWithLostData. After executing commitRestoreWithLostData, you should log in and perform an object audit to determine the extent of the problems, and if possible, attempt to repair the issues.

Automatic commitRestore change

Backups taken from repositories with transaction logs written to /dev/null, or in partial logging mode, normally automatically perform the commitRestore when the backup is completed (since it is not possible to restore tranlogs). If corruption is detected, however, the restore will return BKUP_ERR_RESTORE_FAILURE/4152. The restore is not automatically committed, and you must execute commitRestoreWithLostData in order to commit the restore.

performOnServer: blocked all signals

During the vfork() call invoked by System class >> performOnServer:, all signals are blocked (this was done to avoid a deadlock). Now, SIGTERM is not blocked during the fork. (#47409)

perform:* methods misleading error for an argument count mismatch

When the method selector sent to perform: had a mismatch with the number of arguments (the number of with: keywords used), the error message indicated a message not understood with invalid detail string. (#47448)

Adds to an RcLowMaintenanceIdentityBag were too slow

Adding individual elements to an RcLowMaintenanceIdentityBag was significantly slower than adding to a RcIdentityBag. (#47452)

Stone performance impact when RcTransQueueSize is high

The stone consumed excessive amounts of CPU, and performance was degraded, when handling a large number of sessions doing commits involving RC (reduced conflict) objects during the same time window. (#47647)

RcQueue may have incorrectly returned a nil element

When one session is performing a cleanup and another session is using the queue, there is an incorrect sequence of events in conflict resolution handling. The result is a nil element may be returned from the queue when not expected. No data is lost in this scenario. (#47445)

Float exponent and mantissa incorrect for subnormal floats

The values returned by the exponent and mantissa methods, and values derived from these, were incorrect for subnormal instances of Float; that is, floats that are larger than zero but smaller than the smallest possible positive Float. (#47642)

Empty repeat block caused SEGV

Executing the reserved selector repeat with a block that was entirely empty caused the method compiler to SEGV. (#47635)

Exception>>pass fails when target of pass is a zero argument block

It is legal to use a zero-argument block for the do: argument in an on:do: statement. However, this zero argument block failed with a subsequent pass. (#47456)

Windows client connection error messages

When the connection between the client on windows and the Gem is lost, the Gem log included a unhelpful error "Failed after 0 attempts in sending Error response to GCI client". This now reports a slightly more useful error, for example, "SSL_read(6,0x7f8abd816010,16256) failed with errno=104,ECONNRESET, Connection reset by peer
Error Category: 231169 [GemStone] Number: 4137 Arg Count: 0 Context : 20 exception : 20 "


Intermittent SocketError SSL_shutdown:uninitialized

In situations involving the finalizing of GsSecureSockets instance that were not fully connected, there can be intermittent cases of SocketError, with details similar to: error:140E0114:SSL routines:SSL_shutdown:uninitialized:ssl/ssl_lib. (#47463)

topaz truncated byte output

With the setting limit bytes 0, there should be no byte limit on the output. Topaz was incorrectly truncating at 32500 bytes. (#47521)