Bug #12194 Valgrind: Source and destination overlap in memcpy

Description:
I've been working with Guilhem to run valgrind on a special compile of MySQL Cluster 4.1.12. I've found numerous reports of "Source and destination overlap in memcpy" in the following tests:

 - type_timestamp
 - type_year

Guilhem tells me that these are significant because, "means that memcpy() is copying data over itself (thus is a useless call, probably weird)."

How to repeat:
Run ./mysql-test-run --valgrind-all on special debug copy of mysql-cluster (ask Matt in ENG where to find).

Matt,
it could also mean that memmove() should be used instead of memcpy().

same problems repeating as with Bug #12193.

==7769== Source and destination overlap in memcpy(0x76D76A1, 0x76D76A1, 1)
==7769==    at 0x4022C36: memcpy (mc_replace_strmem.c:116)
==7769==    by 0x836FF37: field_conv(Field*, Field*) (field_conv.cc:708)
==7769==    by 0x817E2A1: Item_field::save_in_field(Field*, bool) (item.cc:4318)
==7769==    by 0x83C89C6: sp_eval_expr(THD*, Field*, Item**) (sp_head.cc:361)
==7769==    by 0x83D1CF6: sp_rcontext::set_variable(THD*, Field*, Item**) (sp_rcontext.cc:355)

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/18300

ChangeSet@1.2598, 2007-01-17 17:46:26-05:00, cmiller@zippy.cornsilk.net +1 -0
  Bug#12194: Valgrind: Source and destination overlap in memcpy
  
  memcpy() must not be given two memory regions that overlap.  memmove()
  handles such memory properly and costs little extra.
  
  I found one instance in my valgrind run of 5.1, in test "sp":
  ==7769== Source and destination overlap in memcpy(0x76D76A1, 0x76D76A1, 1)
  ==7769==    at 0x4022C36: memcpy (mc_replace_strmem.c:116)
  ==7769==    by 0x836FF37: field_conv(Field*, Field*) (field_conv.cc:708)
  ==7769==    by 0x817E2A1: Item_field::save_in_field(Field*, bool) (item.cc:4318)
  ==7769==    by 0x83C89C6: sp_eval_expr(THD*, Field*, Item**) (sp_head.cc:361)
  ==7769==    by 0x83D1CF6: sp_rcontext::set_variable(THD*, Field*, Item**) (sp_rcontext.cc:355)
  ==7769==    by 0x83D1D2A: sp_rcontext::set_variable(THD*, unsigned, Item**) (sp_rcontext.cc:342)
  ==7769==    by 0x821559D: select_dumpvar::send_data(List<Item>&) (sql_class.cc:1958)

I get the error for type_timestamp using 5.0.37 with a 32-bit debug build for Linux 2.6 and x86. The code from field_conv() is below. It is odd that there is a hack to avoid the compiler warnings only for purify builds. Although, this might not be breaking anything because the source and dest pointers are the same.

    {						// Identical fields
#ifdef HAVE_purify
      /* This may happen if one does 'UPDATE ... SET x=x' */
      if (to->ptr != from->ptr)
#endif
        memcpy(to->ptr,from->ptr,to->pack_length());
      return 0;
    }
  }

The warning is:
==5081== Source and destination overlap in memcpy(0x1BC16921, 0x1BC16921, 4)
==5081==    at 0x1B902851: memcpy (mac_replace_strmem.c:394)
==5081==    by 0x826DAA6: field_conv(Field*, Field*) (field_conv.cc:709)
==5081==    by 0x80FCE81: Item_field::save_in_field(Field*, bool) (item.cc:4257)
==5081==    by 0x81BE3E1: fill_record(THD*, List<Item>&, List<Item>&, bool) (sql_base.cc:5088)
==5081==    by 0x81BE4C7: fill_record_n_invoke_before_triggers(THD*, List<Item>&, List<Item>&, bool, Table_triggers_list*, trg_event_type) (sql_base.cc:5127)
==5081==    by 0x81FB414: mysql_update(THD*, st_table_list*, List<Item>&, List<Item>&, Item*, unsigned, st_order*, unsigned long long, enum_duplicates, bool) (sql_update.cc:448)
==5081==    by 0x818E450: mysql_execute_command(THD*) (sql_parse.cc:3423)
==5081==    by 0x819499A: mysql_parse(THD*, char*, unsigned) (sql_parse.cc:5948)
==5081==    by 0x818A322: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1786)
==5081==    by 0x8189B10: do_command(THD*) (sql_parse.cc:1568)
==5081==    by 0x8188C03: handle_one_connection (sql_parse.cc:1194)
==5081==    by 0x1B938CAB: pthread_start_thread (manager.c:310)
==5081==    by 0x1BB82129: clone (clone.S:119)