MySQL Bugs: #27198: Error returns from time() are ignored

Bug #27198	Error returns from time() are ignored
Submitted:	16 Mar 2007 5:57	Modified:	18 Jul 2007 21:21
Reporter:	Arjen Lentz
Status:	Closed
Category:	Server	Severity:	S2 (Serious)
Version:	4.0, 4.1, 5.0, 5.1	OS:	Any (any)
Assigned to:	Tatjana A. Nuernberg	Target Version:
Tags:	bfsm_2007_04_05, error, time, unix_timestamp

Description:
UNIX_TIMESTAMP() uses the value of THD::query_start(). query_start() returns
THD::start_time and that is set from the result of a call to time(). time() can fail, but
THD::set_time() uses the result regardless of whether an error occurred. time() returns -1
on error.

Calls to gettimeofday() done in our customized version of mysqld can fail. The failures
are very infrequent, but they occur. Given that, it's assumed that that time() also fails
occasionally. Given that this is used for unix_timestamp(), it would be preferre that
THD::set_time be changed to check the return value for an error.

How to repeat:
Check in source code.

Thank you for the report.

Verified as described.

according to 'man time' it can only fail if

   EFAULT result buffer points outside the accessible address space.

which cannot be the case in MySQL

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/30885

ChangeSet@1.2214, 2007-07-13 17:50:58+02:00, tnurnberg@sin.intern.azundris.com +2 -0
  Bug#27198: Error returns from time() are ignored
  
  gettimeofday() can fail and presumably, so can time().
  Keep an eye on it.
  
  Since we have no data on this at all so far, we just
  retry on failure (and log the event), assuming that
  this is just an intermittant failure. This might of
  course hang the threat until we succeed. Once we know
  more about these failures, an appropriate more clever
  scheme may be picked (only try so many times per thread,
  etc., if that fails, return last "good" time() we got or
  some such).  Using sql_print_information() to log as this
  probably only occurs in high load scenarios where the debug-
  trace likely is disabled (or might interfere with testing
  the effect).  No test-case as this is a non-deterministic
  issue.

pushed to maint versions of 4.0.31, 4.1.24, 5.0.46, 5.1.21

Pushed into 4.0.31

Noted in 4.0.31, 4.1.24, 5.0.46, 5.1.21 changelogs.

Error returns from the time() system call were ignored.

Pushed into 5.1.21-beta

Pushed into 5.0.48

Pushed into 4.1.24