Rare clock jumps of around 4.3 seconds were seen in a 32-bit Windows application.  GStreamer and the app were built with MinGW/GCC, so the problem probably applies to any 32-bit environment.

The reader/writer locks in gstclock.c guarantee consistent calibration values.  However, they don't make load/stores of "last_time" atomic.

Here's where I think the problem occurs:

The value of time is close to a value that would carry from the low word to the high.  Say 0x00000000 FFFFFFFF.

A thread is executing:
  priv->last_time = MAX (ret, priv->last_time);
It has read the FFFFFFFF

Another thread interrupts the first and updates last_time to
0x00000001 00000000

The first thread resumes and reads the high word yielding 
0x00000001 FFFFFFFF
which it stores in last_time.
Note FFFFFFFF is around 4.3 seconds in ns.

My fix is to use GST_OBJECT_LOCK/UNLOCK in place of read_seqbegin/read_seqretry.  This has no measurable performance impact in my application.  It seems to fix the problem, but since the problem occurs rarely, more testing is needed.