1. GemStone/S 64 Bit 3.4.4 Release Notes

GBS version 8.4

GBS version 8.3

GBS version 5.4.5

GBS version 5.4.4

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

Updated library versions

• The version of lz4 has been updated to v1.9.1.
• The version of OpenSSL has been updated to 1.1.1c.
• The version of OpenLDAP has been updated to 2.4.47.

Updated ZoneInfo (TimeZone database)

The zoneinfo TimeZone database has been updated from version 2017b to 2019a. As part of this update, the files within the timezone directory tree have been reorganized to adhere more closely to standard directory naming conventions.

Raspberry Pi

An initial version of support for GemStone clients running on Raspberry Pi is now provided. The Raspberry Pi runs Linux distribution "Raspian", which is a Debian Linux variant.

Raspberry Pi is a client-only distribution with the name GemStone64BitClient3.4.4-arm.Linux. No specific Installation Guide has been created; the process is similar to a client-only installation on Linux.

Clients Smalltalks have been verified:

• GBS/VA v5.4.5 with VA Smalltalk v9.2 early access (ECAP). Raspberry Pi is provided as a preview feature in this unreleased distribution of VA Smalltalk.
• GBS/VW 8.4 with VisualWorks Smalltalk v8.3.2 Raspberry Pi is provided as unsupported platform in this release.

These configurations are provided for experimentation and are not certified nor fully supported. They should be tested carefully for suitability and should not be used for critical systems.

gslist no longer distributed on Windows

The gslist utility was previously included in the distribution on Windows, but was of minor value since no GemStone server processes can run on Windows. It is no longer included in the Windows distribution.

Compressed backups using lz4 have improved compression

Lz4 backups could be significant larger than the gzip version. The default lz4 file compression level has been changed from 0 to 3, reducing the resulting compressed backup size differential.

The restore of a fullbackup now reduces the OOP high water mark

When a programmatic backup of a GemStone database is made, it now records the actual highest value of an OOP in the repository. This is used on restore of the backup, and may mean the size and number of pages required by the object table is reduced. (#48094).

Reduced space used by object table leaf pages after restore

During restore of backup, leaf pages may be created in the object table that do not end up being needed. The allocation of these pages has changed so the pages are only allocated if needed. (#48093)

pageaudit additional statistics

pageaudit, in addition to reporting if there are any errors found in the page allocation with a repository, also reports statistics about the repository pages. This information is written to the pageaudit log file, tmpstnname-pageAudit.log.

The additional lines of information include:

OT Internal Pages                0.05 Mbytes          3 pages

OT Leaf Pages                    0.81 Mbytes         52 pages

Empty OT leaf pages              0.00 Mbytes          0 pages

Empty data pages                 0.00 Mbytes          0 pages

Data pages with 25%+ free        5.94 Mbytes        380 pages

Data pages with 50%+ free        4.05 Mbytes        259 pages

Free space in data pages         4.25 Mbytes     272.25 pages

This additional information allows you to verify the page distribution following a restore.

During restore, possible C heap growth and CR backlog

When restoring transaction logs, such as in a warm standby, the tranlog reader thread was reading ahead too far, resulting in excessive C heap growth. In addition, the commit record was not always released in a timely manner during tranlog restore, which lead to a commit record backlog. (#48214)

The statmonitor stat BmCHeapPages, that measures C heap usage, wrapped and was unreliable (#48216)

backup start time was not reported in stone log

The stone log normally contains the time a full programmatic backup was started and the time it completed. The start message was not being included. (#48100)

Statmonitor automatic delete of older data files

You can now configure statmonitor with automatic new file creation to automatically delete older files. Using the -K numFiles flag to statmonitor, you can specify the number of older files to save (not including the file currently being updated). You may only use -K with either -r or -R.

Statmonitor automatic start failed with -X

Starting up a statmonitor -X using configuration parameters such as STN_STATMONITOR_ARGS did not work, as these methods automatically include the stone or cache name as an argument. The -X option provides host-only monitoring and no stone or cache name is permitted as an argument. The -X option is now handled, but note that there are limitations in the log file names permitted within the -F argument in this mode. (#47885)

Automatic start of statmonitor did not occur during pageaudit

Setting a value for STN_STATMONITOR_ARGS means that statmonitor should start automatically when the stone runs; this was not occurring during pageaudit. (#47674)

Linker symbols now weak on Linux

Support for GCI application on Ubuntu 18.04 required some changes in the way GemStone shared libraries are built. The shared libraries now contain weak symbols, and the linker flags for linking a GCI application have changed.

Otherwise, this change should have no impact on customer applications.

Stack traces on Windows for fatal errors

On Windows, access violation errors (e.g. SEGV) from RPC GCI will now provide a C stack for subsequent debugging. All GCI calls will handle access violations this way. The stack is written to the GCI trace file, if that is active, or to a file with the name GCI*.tmp in the windows temporary directory,

c:\users\userid\AppData\Local\Temp\

Note that the .pdb files from the GemStone Windows Client distribution must be present in order to capture a stack trace.

GciErrSType class >> new incorrect malloc size

The implementation was configured to malloc 2163 bytes, which did not allow for the round-up to 32-bit word boundaries, and should have been 2168. (#47304)

SIGTERM handler not chained to installed handler in linked GCI

In the libgcilnk library, but not in the libgcirpc library, a SIGTERM handler is not chained to a previously installed handler. (#47862)

Reported bytes sent/received incorrect

Removed statistics

The following statistic has been removed:

ServiceMs

Added statistics

The following statistics have been added:

ReadWaitMs (HardDisk)
The average number of milliseconds to service a read I/O, including both time spent in the I/O queue and time performing the read.

WriteWaitMs (HardDisk)
The average number of milliseconds to service a write I/O, including both time spent in the I/O queue and time performing the write.

Failure to recover after loss of pageserver for a remote cache

When the pageserver on the Stone's note that services a remote cache dies, the remote cache should shutdown and a subsequent login on that remote node should trigger the restart of the remote cache. However, login attempts during the period could prevent the remote cache from shutting down to complete the recovery. (#48166)

Extent names not updated on remote cache

When a new extent was created at runtime, the cached list of extent names was not updated in a remote cache unless a new gem logged into the remote cache. (#48183)

STN_COMMITS_ASYNC risky and use has been disabled

Testing encountered a case in which with this configuration parameter set to true, a record was missing from the transaction log during restore after the Stone ran out of tranlog disk space. (#48098) To avoid risk, this parameter has been disabled in v3.4.4.

SHR_PAGE_CACHE_PERMISSIONS printed without leading 0

The value for SHR_PAGE_CACHE_PERMISSIONS was printed in log files without the leading ’0’, which caused it to be interpreted as decimal. Now, the logs show the usable value that includes the leading 0. (#48157)

Errors in STN_GEM_INITIAL_TRANSACTION_MODE caused log bloat

The error reported when there was an parsing error in the value for the configuration parameter STN_GEM_INITIAL_TRANSACTION_MODE was not handled correctly and caused startup to fail and excess printing in the stone log.

STN_FREE_SPACE_THRESHOLD value greater than 4GB was truncated

If the setting for STN_FREE_SPACE_THRESHOLD is specified to be greater than 232-1 (4294967295), the value that is actually set is the value truncated to the low-order 32 bits of the number, resulting in a value no greater than 65K (#48211).

GsExternalSession failed with gemNRS: string argument

GsExternalSession login parameters can accept an instance of GsNetworkResourceString, or a String containing NRS as an argument. The use of strings for the gemNRS: parameter was broken. (#47868)

Logout problems in certain configurations

The tests to determine if Gem was correctly logged out did not take into account the possible existence of a stone with the same name running on the Gem host but not used to login the External session; nor a Gem running on a remote node. While the logout proceeded correctly, the return would not complete and the logout would appear to hang. (#47663)

Logreceiver race condition could cause tranlog read failure

There is a race condition in logreceiver logic that can cause the slave stone to attempt to read from a newly transferred tranlog before any data has been permanently flushed to disk. This will generate errors claiming that the file is not a GemStone transaction log file. (#47844)

Logsender added padding to tranlog records when compressing

During compression, the logsender added padding to the tranlog records. This was unnecessary; and the cumulative padding could cause buffer overrun. (#47916)

Invalid version number in extents, confusing later upgrade errors

The GemStone extents store internal version numbers, to verify compatibility between versions. While the numbers for the checks were correct, the version number stored for reporting errors was ’820.0’, which made the error messages unclear. This has been corrected, so upgrading from 3.4.4 or later 3.4.x versions to future versions will be able to report useful error messages. (#49752)

After upgrade, GcGems not running

During the Stone restart during upgrade, the Reclaim and Admin GcGem/s were started, but could not login due to a version mismatch, and no further startup attempts were made after upgrade. This left the upgraded system without the GcGems running. (#47884)