Bug #16836 infinite loop caused by subtle merge conflict
Submitted: 27 Jan 2006 11:40 Modified: 27 Jan 2006 18:16
Reporter: Kristian Nielsen Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.1.6 (latest bk) OS:
Assigned to: Assigned Account CPU Architecture:Any

[27 Jan 2006 11:40] Kristian Nielsen
Description:
While fixing Windows build problems I found this (Visual Studio complains about infinite recursion).

You did this change in sql/field.cc, Field_date::store(double):

======== field.cc 1.256.7.1 ========
D 1.256.7.1 05/07/18 16:12:41-07:00 jimw@mysql.com 526 516 91/118/8552
P sql/field.cc
C Update conversion of numbers to date, datetime, and timestamp to
C use number_to_datetime() and report errors and warnings correctly
C and consistently.

  longlong tmp;
...
-    longstore(ptr,tmp);
-  return error;
+  return Field_date::store(tmp);
 }
 
  int Field_date::store(longlong nr)
 {

In parallel, Monty did this change:

======== field.cc 1.256.1.26 ========
D 1.256.1.26 05/09/14 01:41:37+03:00 monty@mishka.mysql.fi 544 542 131/80/8575
P sql/field.cc
C Added flag to Field::store(longlong) to specify if value is unsigned

-int Field_new_decimal::store(longlong nr)
+int Field_new_decimal::store(longlong nr, bool unsigned_val)

Do you see the problem? You added a call to Field_date::store(longlong) in parallel with Monty adding a new argument to Field_date::store(longlong). This automerges, but wrongly of course (the classic merge problem). Now your call of Field_date::store() is recursive (by an implicit conversion longlong -> double).

How to repeat:
Source inspection.

Suggested fix:
Add an appropriate argument to the nested Field_date::store() call so that the correct overloaded version is picked up.
[27 Jan 2006 18:16] Jim Winstead
Duplicate of Bug #15634, as Miguel noted.