1. GemStone/S 64 Bit 3.5.8 Release Notes 
Overview
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
GBS version 8.4
GBS version 5.4.6
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
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:.
restoreFromBackup:newSystemUserPassword:
restoreFromBackups:newSystemUserPassword:
restoreFromSecureBackup:privateDecryptionKey:
passphrase:newSystemUserPassword:
restoreFromSecureBackup:privateDecryptionKey:passphraseFile:
newSystemUserPassword:
restoreFromSecureBackups:privateDecryptionKey:passphrase:
newSystemUserPassword:
restoreFromSecureBackups:scavengePagesWithPercentFree:
privateDecryptionKey:passphrase: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:
restoreFromSecureBackups:privateDecryptionKey:passphraseFile:
restoreFromSecureBackups:privateDecryptionKey:passphraseFile:
newSystemUserPassword:
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:.
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
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.
NonPersistentArray
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:
isError:
isFailure:
isPassed:
Removed methods
The following private methods have been removed:
Repository >> _primRestoreSecureBackups:scavPercentFree:
bufSize:privateDecryptionKey:passphrase:numThreads:
Repository >> _restoreBackups:scavPercentFree:bufSize:
numThreads:
UserProfile >> _validateUserProfileAccess
Added Error
The following error as been added, as part of the changes for bug 49715, described here.
Cache statistics changes
The following cache statistic has been added, as part of the changes for bug #49771, described here.
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)
SPC Monitor crash with SHR_PAGE_CACHE_LARGE_MEMORY_PAGE_SIZE_MB=0
SHR_PAGE_CACHE_LARGE_MEMORY_PAGE_SIZE_MB=0;
SHR_PAGE_CACHE_LARGE_MEMORY_PAGE_POLICY=2;
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:
totalExtentGrows
timeInExtentGrows
avgTimePerExtentGrow
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)