Sanja will probably rework this tomorrow; we need to unify the normal

client code and replication slave code, as far as LOAD DATA INFILE and
other queries' execution is concerned. Duplication of code leads to
replication bugs, because the replication duplicate lags much behind.
Fix for 2 Valgrind errors on slave replicating LOAD DATA INFILE
  - one serious (causing a random test failure in rpl_loaddata in 5.0)
  - one not serious (theoretically a bug but not dangerous): uninited thd->row_count


sql/log_event.cc:
  Fix for 2 Valgrind errors:
  - one serious (causing a random test failure in rpl_loaddata in 5.0): uninited lex in replic of LOAD DATA INFILE on slave
  - one not serious (theoretically a bug but not dangerous): uninited thd->row_count in replication of LOAD DATA INFILE on slave.
  Sanja is likely to rework the fix to the 1st problem tomorrow.

sql/log_event.cc

@@ -1702,6 +1702,11 @@ int Load_log_event::exec_event(NET* net, struct st_relay_log_info* rli,
   thd->query_length= 0;                         // Should not be needed
   thd->query_error= 0;
   clear_all_errors(thd, rli);
+  /*
+    Usually mysql_init_query() is called by mysql_parse(), but we need it here
+    as the present method does not call mysql_parse().
+  */
+  mysql_init_query(thd);
   if (!use_rli_only_for_errors)
   {
 #if MYSQL_VERSION_ID < 50000
@@ -1730,6 +1735,13 @@ int Load_log_event::exec_event(NET* net, struct st_relay_log_info* rli,
     VOID(pthread_mutex_lock(&LOCK_thread_count));
     thd->query_id = query_id++;
     VOID(pthread_mutex_unlock(&LOCK_thread_count));
+    /*
+      Initing thd->row_count is not necessary in theory as this variable has no
+      influence in the case of the slave SQL thread (it is used to generate a
+      "data truncated" warning but which is absorbed and never gets to the
+      error log); still we init it to avoid a Valgrind message.
+    */
+    mysql_reset_errors(thd);
 
     TABLE_LIST tables;
     bzero((char*) &tables,sizeof(tables));