1. GemStone/S 64 Bit 3.5.6 Release Notes


GemStone/S 64 Bitâ„¢ 3.5.6 is a new version of the GemStone/S 64 Bit object server, including fixes for a critical bug involving nested transactions, issues with LDAP, as well as other bug fixes.

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

The Installation Guide for Mac, but not for other platforms, has been updated for v3.5.6, to reflect additional configuration requirements for Big Sur. For details on installing or upgrading on other platforms, see the GemStone/S 64 Bit Installation Guide for v3.5.3 for that platform.

Supported Platforms

Platforms for Version 3.5.6

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

  • Red Hat Enterprise Linux Server and CentOS Linux 6.10, 7.9, and 8.3; Ubuntu 16.04, 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.6 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.6.

GBS version 8.5





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





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

VAST platform

VAST platform

VAST platform

  • Windows 10                     
  • Windows 10                    
  • Windows 10 and Windows 7
GBS version 5.4.5

VAST platform

VAST platform

  • Windows 10                     
  • Windows 10 and Windows 7

Windows 7 reached end of life in January of 2020. While GemTalk continues to test on and support GemStone clients on Windows 7, it is no longer considered fully certified.

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.6 distribution includes VSD v5.5.1. This is the same version that was included with GemStone/S Bit v3.5.5; the updated build number reflects added statistics definitions.

Changes in this release

Updated library version

  • The version of OpenSSL has been updated to 1.1.1k.
  • The version of MIT Kerberos has been updated to 1.19.1.
  • The version of OpenLDAP has been updated to 2.4.58.
  • The version of zoneinfo has been updated to 2021a.

Support for Mac "Big Sur"

Configuring shared memory on "Big Sur" requires special handling. The Installation Guide for Mac for v3.5.6 includes details, or see the (informational) bugnote for 49319.

LdapDirectoryServer now supports TLS options

The following instance variables have been added to LdapDirectoryServer, allow you to control the LDAP TLS options from GemStone rather than from LDAP configuration files. This is necessary when the process is in setuid mode.

Specifies the default base DN to use when performing ldap operations. The base DN must be specified as a Distinguished Name in LDAP format.

Specifies the file that contains certificates for all of the Certificate Authorities the client will recognize.

Specifies the path of a directory that contains Certificate Authority certificates in separate individual files. tlsCaCert is always used before tlsCaCertDir.

Specifies the file that contains the client certificate.

Specifies the file that contains the private key that matches the certificate stored in the tlsCert instance variable. The private key must not have a passphrase.

A symbol which specifies what checks to perform on server certificates in a TLS session, if any. The following symbols are recognized:

#never - The client will not request or check a server certificate.

#allow - The server certificate is requested. if not provided or if the certificate is invalid, it is ignored and the session proceeds normally.

#try - the server certificate is requested. If not provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated.

#demand (the default) - the server certificate is requested; if not provided or if the certificate is invalid, the session is immediately terminated.

Added LdapDirectoryServer methods

The following methods have been added:

LdapDirectoryServer >> validatePassword: aPassword forUserId: aUserId withBaseDn: aBaseDn filterDn: aFilterDn
Use the receiver LdapDirectoryServer to validate the given userId and password. See the method comments for examples on using this method for validation.

LdapDirectoryServer class >> basicNewWithUri: uri bindDN: aBindDn password: password baseDN: baseDn tlsCaCert: caCert tlsCert: cert tlsKey: key tlsReqCert: aSymbol
Creates a new instance of the receiver but does not add it to the list of LdapDirectoryServer objects used to authorize logins.

LdapDirectoryServer class >> newWithUri: uri bindDN: aBindDn password: password baseDN: baseDn tlsCaCert: caCert tlsCert: cert tlsKey: key tlsReqCert: aSymbol
Creates a new instance of the receiver and adds the resulting object to the list of LdapDirectoryServer objects used to authorize logins.

LdapDirectoryServer class >> testConnectionToServer: uri bindDN: aBindDn password: password baseDN: baseDn tlsCaCert: caCert tlsCert: cert tlsKey: key tlsReqCert: aSymbol
Attempts to perform a bind using aBindDn and password to the LDAP server specified by uri. Also sets the TLS credentials, if those arguments are not nil. Returns true if the connection was successful, otherwise returns false.

Minor change in version.txt

The information in the file $GEMSTONE/version.txt now includes branch information following the date; this is for tracking special builds.

Object >> initialize default implementation

The method Object >> initialize has been added, with an empty operation. This allows subclasses to send "super initialize" from their initialize methods without considering the location within the hierarchy.

Bugs Fixed

Incorrect incremental tranlogging of changes to kinds of IdentityBag from within nested transactions

With incremental tranlogging, only specific changes to collections are logged to the transaction logs, for efficiency. These incremental tranlog entries were incorrect for kinds of IdentityBag, from within nested transactions. Changes to an IdentityBag or a subclass of IdentityBag that are made within a nested transaction, may be written incorrectly to the transaction logs. If the database is later restored from backup and the transaction logs replayed, or if the transaction logs are applied to a warm or hot standby, the collection will be incorrect in the replayed repository; the collection could contain nils instead of valid objects. (#49382)

Added configuration parameter STN_TRAN_INCREMENTAL_LOGGING

To manually control incremental tranlogging, the configuration parameter STN_TRAN_INCREMENTAL_LOGGING has been added. The default is true, providing behavior from previous releases. When false, operations such as changes to collections that are usually incrementally logged are instead logged in full. This will result in larger tranlog volume.

FALSE shuts off the incremental logging of additions or deletions to nodes of large objects, with side effect of more bytes written to tranlogs.
Default TRUE.

Hot standby issues

logsender may read incomplete tranlog records

In a hotstandby system, when the logsender transmit records to the logreceiver, there is the possibility that while the write operation completed, the disk fsync was not complete, and so the record read from disk by the logsender and sent to the logreceiver may be incomplete. (#49449)

A related problem still exists in this version, in the case where the logsender is not connected to the master Stone (using the -s flag), and therefore has to rely on disk file writes to detect when a new record is available. A logical record may cross a file system block boundary, and this is not detected by the logsender’s disk file checks. It is strongly encouraged to use the -s flag to avoid this risk; the Stone tracks the logical record boundaries and provides this information to the logsender.

logsender compression buffer too small

There was a chance that the logsender buffer for tranlog compression was too small, resulting in an overflow. (#49501)

ProfMonitor did not automatically delete its file

While ProfMonitor is performing monitored, e.g., using monitorBlock:, it records data in a disk file. These files were not being automatically deleted. (#49406)

Issues related to Symbol Garbage Collection

Cumulative algorithm changes in Symbol GC

Symbol Garbage Collection has undergone a number of internal changes in the algorithm used to ensure behavior is correct for large sets of dead symbols in active repositories, with additional validation on large customer repositories.

Note that the documentation describing the internal algorithms used is no longer correct with respect to current behavior.

Symbol GC may have collected referenced Symbols

A Symbol whose only reference is from an object in the possible dead set, may be garbage collected even if the referencing object is voted to stay alive rather than being promoted to dead. (#49339)

Symbol GC slow with many dead symbols

When Symbol GC found a very large number of possible dead symbols, the write set union sweep became unreasonably slow. This was a result of the possibleDeadSymbol structure containing large collision buckets; the objects referenced from the collision buckets were being read, which is unnecessary, since all contained objects would be symbols. (#49504)

GcGem logging issues

Reclaim log entries omitted

Entries providing information on reclaim activity, after the first entry, were not printed to the ReclaimGem’s log file. (#49388)

Warnings on range test incorrect

Some out of range warnings in the ReclaimGem log displayed incorrect information. (#49396).

On startup, verbose logging was true

On GcGem startup, the values used for the configuration parameters #reclaimVerboseLogging and #adminVerboseLogging were true, regardless of the value previously set. (#49389)

More information printed when reclaimVerboseLogging is true

With #reclaimVerboseLogging set to true, additional information on individual reclaims is now printed in the reclaim log. #(49409)

Upgrade required DataCurator password to be manually reset

The updateImage step requires that you change the password for SystemUser to the default. The SystemUser then changes the password for DataCurator to perform some steps of the login. The order of operations was incorrect in some recent versions, such that DataCurator’s password had to be manually reset as well. (#49365)

LDAP issues

GemStone links the OpenLDAP libraries to provide GemStone authentication directly via LDAP. A number of fixes and improvements to the GemStone API to LDAP are included in this release.

Note that GemStone UNIX authentication, which goes through PAM, may also use LDAP is PAM is configured to use LDAP, but this configuration is outside of GemStone; the changes described here only affect UserProfiles that are configured with authentication mode of #ldap; or calls to LdapDirectoryServer functions from within GemStone to authenticate passwords.

LDAP did not work for processes in setuid mode

If the process is in setuid mode (that is, the real and effective UNIX userIds of a process are not the same), LDAP does not read environment variables, nor files in the $HOME directory, and thus was not able to set all required information to connect to an LDAP server. (#49498)

With a setuid mode process, such as a Gem with the s bit set, you will need to use the new LdapDirectoryServer tls* instance variables within GemStone Smalltalk to set the certificate requirement, and certificates if necessary, that allow connection to the LDAP server. See LdapDirectoryServer now supports TLS options.

GemStone's LDAP library did not correctly set directory for ldap.conf

GemStone's LDAP library, libldap-N.N.N-64.so, looked for ldap.conf in the installation directory, $GEMSTONE, which did not follow LDAP conventions. (#49515)

Now, it will look for /etc/openldap/ldap.conf. This setting can be overridden by environment variables, or by files .ldaprc or ldaprc. Note that the specific LDAP search sequence is distribution dependent; this is the RedHat/CentOS convention. See the ldap.conf man page for your distribution for details.

LDAP did not support reset of TLS credentials

The binding to TLS credentials in LDAP could not be done more than once; so changing TLS credentials required restarting the process. (#49499)

GsHostProcess may run hot while waiting for a long-running command

GsHostProcess >> _execute:input: runs hot while waiting for a long-running command to complete. This affects a number of GsHostProcess >> execute* functions. (#49510)

Cross-version connection to 3.5.x.y versions failed

The code in GciTsLibrary to analyze the version lost the final digit of a dot-dot-dot release in the 3.5.x range, which caused the connection to fail. (#49385)

Memory leak in X509-secured NetLDI and HostAgent

The specialized NetLDI and HostAgent processes that support X509-Secure GemStone logins had a memory leak in the login/logout process. (#49411)

GEM_ABORT_MAX_CRS impacts GBS traversals

The configuration parameter GEM_ABORT_MAX_CRS limits the number of commit records examined on abort. If commit record backlog is larger than this limit, the subsequent traversal result seen by GBS does not include all of the exported objects; updates to replicated but not modified objects in that session, that were changed by other sessions, may not be visible. (#49434)

In addition, the parameter documentation incorrectly stated that a value of 0 meant scan all records; in fact, 0 meant scan no records. (#49448)

Issues related to automatic startup of statmonitor

Stone did not auto-start statmonitor early enough when in recovery

When STN_STATMONITOR_ARGS is set, the Stone starts statmonitor on startup; which is possible as soon as Stone connects to the shared page cache. However, when the Stone was in recovery (after an unclean shutdown), it did not start statmonitor until recovery was complete, which meant no statistics information was available on the recovery itself (#49442)

GEM_STATMONITOR_ARGS did not start statmonitor

When the configuration parameter GEM_STATMONITOR_ARGS is specified, statmonitor should automatically be started on remote node on which a Gem is running. Statmonitor was not successfully starting. (#49463).

On Windows clients, the "RUNNING ON" platform displayed is incorrect

The log files on Windows 10 clients printed a RUNNING ON value of NT 6.2, which is incorrect for Windows 10. (#49294)