1. GemStone/S 64 Bit 3.4.2 Release Notes

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:

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.

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.

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.

System gemConfigurationAt: #GemCommitStubsForNpObjects put: true

Hot standby related changes

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

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:

create_new_dsa_cert.sh

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

certs/backup_sign_3_client_dsa_cert.pem

certs/backup_sign_3_client_dsa_req.pem

private/backup_sign_3_client_dsa_key.pem

private/backup_sign_3_client_dsa_passwd.txt 

Changes in GCI

(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

    );

GCI_UTF8_FetchNormal = 0,

GCI_UTF8_FilterIllegalCodePoints = 0x1,  /* not yet implemented*/

GCI_UTF8_NoError     = 0x2   /* return  message instead of signalling Exception*/

	} GciFetchUtf8Flags ;

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.

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 "

(#47504)

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)