1. GemStone/S 64 Bit 3.2.13 Release Notes 
Overview
GemStone/S 64 Bit 3.2.13 is a new version of the GemStone/S 64 Bit object server. This release includes a number of bug fixes and other improvements; we recommend everyone using GemStone/S 64 Bit v3.2.x upgrade to this new version.
These release notes provide changes between the previous version of GemStone/S 64 Bit, version 3.2.12, and version 3.2.13. If you are upgrading from a version prior to 3.2.12, review the release notes for each intermediate release to see the full set of changes.
For installation, upgrade and conversion instructions, use the Installation Guide for version 3.2.6. Note that application code recompilation is now recommended; see Upgrade.
Supported Platforms
Platforms for Version 3.2.13
GemStone/S 64 Bit version 3.2.13 is supported on the following platforms:
- Solaris 10 and 11 on SPARC
- Solaris 10 on x86
- AIX 6.1 and AIX 7.1
- Red Hat Linux ES 6.4 and 6.5, Ubuntu 12.04, and SUSE Linux Enterprise 12, on x86
- Mac OSX 10.6.8 (Snow Leopard), with Darwin 10.8.0 kernel, on x86
For more information and detailed requirements for supported platforms, please refer to the GemStone/S 64 Bit Installation Guide for that platform.
GBS Versions
The following versions of GBS are supported with GemStone/S 64 Bit version 3.2.13. You must use GBS version 7.6.1 or later for VisualWorks, or 5.4.2 or later for VA Smalltalk with GemStone/S 64 Bit v3.2.13.
GBS version 8.1
GBS version 7.6.1
VSD Version
The GemStone/S 64 Bit v3.2.13 distribution includes VSD version 5.1.2. The previous version of GemStone/S 64 Bit, v3.2.12, included VSD v5.1.
Between v5.1 and v5.1.2, the changes include:
- changes in the statistic type for a number of statistics, affecting combined graphs.
- Incorrect chart values when data is displayed on little-endian systems (AIX and solaris/SPARC).
- On Windows, some statistic values wrap to negative when value exceeds 231
For more details, see the Release Notes for VSD v5.1.1 and v5.1.2.
Upgrade
The upgrade process from 3.1.x to 3.2.x did not specify that method recompilation was required.
However, there were minor changes in the bytecodes generated from method compilation between v3.1.x and 3.2.x, related to the changes that allow a step point at the beginning of a method.
A case has been observed in which a SEGV in a Gem was apparently related to this difference in the bytecodes. While this is a very rare situation and is not believed to be at risk for causing any other problems, for reliability it is recommended that all application methods be recompiled as part of the 3.1.x to 3.2.x upgrade process.
Changes and Bug Fixes
Updated SSL libraries
The version of OpenSSL used by GemStone/S 64 Bit v3.2.7 has been updated to 1.0.2g.
GsFile atEnd now returns true for empty file
When GsFile opened an empty file, previously the atEnd message returned false. Now, it will return true.
Handling of reused PIDs in defunct lock files
gslist looks at GemStone lock (..LCK) files to determine what GemStone server processes (Stones, NetLDIs, etc.) are running. The lock files include information about the server process, including the PID of the process.
In earlier versions, gslist only verified that the PID was running, not that the process using that PID was the same GemStone server process. If a process was killed, leaving the lock file behind, and that PID was reused, gslist assumed the PID was valid. The server name/lock file were stuck, and the lock file had to be manually deleted.
Now, on Linux only, lock files involving reused PIDs are handled correctly, by checking in /proc/PID/.
- gslist always checks for the correct process pid, and will report such servers as killed, not OK.
- gslist -c will clear the lock file
- startnetldi will clear the lock file and start the requested netldi.
On platforms other than Linux, you must still manually delete the lock file.
gslist -x did not show startnetldi -D value
The -D option was added in recent versions of GemStone. The value of this argument was not reported in the results of gslist -x. (#45935)
NetLDI socket leak on incompatible connection
When the NetLDI opened a connection to an incompatible version of GemStone, there was a code path in which the socket connection was not closed, resulting in a socket leak in the NetLDI. (#45902)
Conversion and Upgrade issues
Conversion from 2.4.x to 3.2.x could fail after Symbol conversion with corrupt object error
During the symbol conversion phase of the 2.4.x to 3.2.x conversion, a data page could end up with an out of range clusterId. This resulted in a corrupt object error. (#46032)
Conversion problems with very large Symbols
GemStone/S 64 Bit does not allow Symbols larger than 1024 bytes. However, repositories converted from 32-bit may contain Symbols that are larger, including ones larger than 8K that require LargeObjectNodes for internal storage.
During the conversion to 3.x, startstone -C resorts AllSymbols; this sort operation will fail if any symbols over 8K are present, causing the startstone -C to fail. (#45923)
As of this version, the startstone -C conversion will not fail; any symbols over 8K are removed from AllSymbols. These symbols remain as uncanonical symbols and can be removed or, if unreferenced, will be removed by garbage collection. It is recommended that before conversion, you examine your repository for large symbols and convert appropriately.
Filein class definitions that fail in _equivalentSubclass:... did not provide details
When a class definition is filed in, it invokes the method
Class>>_equivalentSubclass:superCls:name:newOpts:newFormat:
newInstVars:newClassInstVars:newPools:newClassVars:inDict:
constraints:isKernel:
to determine if a new version of the class should be created, or if the definition is the same in all ways. When this method determined that the classes were not the same, it did not provide details about the specific cause of the failure, which made analysis of upgrade/conversion issues difficult. (#45836)
Upgrade issues for SessionMethods installed for users other than DataCurator
The GLASS/Seaside/GsDevKit environment uses Session Methods, an undocumented feature allowing session-specific methods to be installed. The upgrade process expected Session Methods to be in the UserGlobals of DataCurator.
The upgradeSeasideImage script now includes -u <user> and -p <password> optional arguments, which can be used when upgrading systems in which Seaside/GLASS/GsDevKit was not installed as DataCurator. (#45746)
After remote cache startup timeout, cache status may be stuck
If a remote cache fails to complete startup within the time period of STN_REMOTE_CACHE_STARTUP_TIMEOUT, the stone starts shutting down and cleaning up after the startup attempt. There were timing cases in which the remote cache could complete the startup and shut itself down, leaving the Stone status incorrect. (#46020)
Checkpoints not written during replay of possible dead objects
Stopping and restarting the Stone during the restore of transaction logs that include a reclaim of possible dead, required that the reclaim restart from the beginning. Now, checkpoints are written during the replay. The main impact of this would be on warm and hot standby systems. (#45901)
Large operations on hidden sets can run out of ME object memory space
Operations on hidden sets, such as System>>hiddenSetEnumerate:limit:, against very large bitmaps could encounter a logic error that filled the ME space part of temporary object memory. In-memory garbage collection was not triggered when ME Space was full but other spaces did not need GC. This resulted in an error "VM temporary object memory is full , ME-space overflow" errors (4067), which could not be trapped using the AlmostOutOfMemory exception. (#46054, #46058)
Reclaim Gem may startup in transaction
When the stone starts up and has to recover due to an unclean shutdown, and there were pages to reclaim, then the Reclaim Gem started up in transaction. This could cause a commit record backlog until recovery completed, or Reclaim Gems’ maxTransactionDuration was reached. (#46005)
Indexing issues
IndexingErrorPreventingCommit error not informative
After an indexing error occurs, commits may be disallowed to avoid committing an inconsistent state of the indexes. The Exception IndexingErrorPreventingCommit did not itself provide any details of what the error was; now, the details of the original error are added to the IndexingErrorPreventingCommit error details. (#44749, 45812)
This does not affect cases of indexing state preventing commit that originate in the VM.
Message Not Understood during processing indexing error
Some cases of indexing errors reported an MNU on #'_idxBasicCanCompareWithUnicodeInstance:'. Now, the regular error message is reported. (#44429)
Index creation with autoCommit and manual transaction mode leaves session in transaction
In manual transaction mode when indexing autoCommit is enabled, when an indexing operation is performed, the system starts a transaction , performs the task, and commits; it should then leave the session in the same state as prior to the operation was started. However, a number of indexing operations, including createEqualityIndexOn: withLastElementClass:, on completion left the session in transaction. (#45896)
StringKeyValueDictionary>>at:ifAbsent: did not use block on nil argument
The methods StringKeyValueDictionary >> at:ifAbsent: and StringKeyValueDictionary >> at:otherwise: returned the error #rtErrNilKey (error 2090) when the specified key was nil, rather than executing the block supplied to handle nil keys. (#45367)
upgradeSeasideImage failed as a result of recently added class GsFailedMethodCompilationDuringCopyMethodToNewClass
After the GLASS/Seaside/GsDevKit class GsFailedMethodCompilationDuringCopyMethodToNewClass was added, the upgradeSeasideImage step failed. (#46059)
topaz output pushnew limit increased
Previously, up to 100 files could be specified; now, 1000 are allowed.