Docs/manual.texi

    updates for new code
sql/mysqld.cc
    catch SIGBUS and SIGILL
    print query and connection id on coredump if possible


Docs/manual.texi:
  updates for new code
sql/mysqld.cc:
  catch SIGBUS and SIGILL
  print query and connection id on coredump if possible

Docs/manual.texi

@@ -1096,7 +1096,9 @@ The @code{mysqlbug} script should be used to generate bug reports.
 @c FIX! RPMs are also binary
 For source distributions, the @code{mysqlbug} script can be found in the
 @file{scripts} directory.  For binary distributions, @code{mysqlbug} can
-be found in the @file{bin} directory.
+be found in the @file{bin} directory. If you have found a sensitive
+security bug in @strong{MySQL}, you should send an email to
+@email{security@@mysql.com}.
 
 @cindex errors, reporting
 @cindex reporting, errors
@@ -20731,6 +20733,11 @@ requires more than this amount of memory, one will get the error
 "Multi-statement transaction required more than 'max_binlog_cache_size'
 bytes of storage".
 
+@item @code{max_binlog_size}. Available after 3.23.33. If a write to the
+binary ( replication) log exceeds the given value, rotate the logs. You
+cannot set it to less than 1024 bytes, or more than 1 GB. Default is
+1 GB.
+
 @item @code{max_connections}
 The number of simultaneous clients allowed. Increasing this value increases
 the number of file descriptors that @code{mysqld} requires.  See below for
@@ -25779,7 +25786,7 @@ below.
 
 @enumerate
 @item
-Make you have a recent version of @strong{MySQL} installed on the master
+Make sure you have a recent version of @strong{MySQL} installed on the master
 and slave(s).
 
 Use Version 3.23.29 or higher. Previous releases used a different binary
@@ -26183,6 +26190,11 @@ summary of commands:
  @tab Re-enables update logging if the user has process privilege.
  Ignored otherwise. (Master)
 
+@item @code{SET SQL_SLAVE_SKIP_COUNTER=n}
+ @tab Skip the next @code{n} events from the master. Only valid when
+the slave thread is not running, otherwise, gives an error. Useful for
+recovering from replication glitches.
+
 @item @code{RESET MASTER}
  @tab Deletes all binary logs listed in the index file, resetting the binlog
 index file to be empty. In pre-3.23.26 versions, @code{FLUSH MASTER} (Master)
@@ -26209,7 +26221,9 @@ CHANGE MASTER TO
   MASTER_HOST='master2.mycompany.com',
   MASTER_USER='replication',
   MASTER_PASSWORD='bigs3cret',
-  MASTER_PORT=3306;
+  MASTER_PORT=3306,
+  MASTER_LOG_FILE='master2-bin.001',
+  MASTER_LOG_POS=4;
 
 @end example
 
@@ -26538,12 +26552,36 @@ privileges for the replication user on the master, master host name, your
 DNS setup, whether the master is actually running, whether it is reachable
 from the slave, and if all that seems ok, read the error logs.
 @item
-If the slave was running, but then stopped, check the error logs. It usually
+If the slave was running, but then stopped, look at SHOW SLAVE STATUS
+output andcheck the error logs. It usually
 happens when some query that succeeded on the master fails on the slave. This
 should never happen if you have taken a proper snapshot of the master, and
 never modify the data on the slave outside of the slave thread. If it does,
 it is a bug, read below on how to report it.
 @item
+If a query on that succeeded on the master refuses to run on the slave, and
+a full database resync ( the proper thing to do ) does not seem feasible,
+try the following:
+@itemize bullet
+@item
+First see if there is some stray record in the way. Understand how it got
+there, then delete it and run @code{SLAVE START}
+@item
+If the above does not work or does not apply, try to understand if it would
+be safe to make the update manually ( if needed) and then ignore the next
+query from the master.
+@item
+If you have decided you can skip the next query, do
+@code{SET SQL_SLAVE_SKIP_COUNTER=1; SLAVE START;} to skip a query that
+does not use auto_increment, last_insert_id or timestamp, or
+@code{SET SQL_SLAVE_SKIP_COUNTER=2; SLAVE START;} otherwise
+@item
+If you are sure the slave started out perfectly in sync with the master,
+and no one has updated  the tables involved outside of slave thread,
+report the bug, so
+you will not have to do the above tricks again.
+@end itemize
+@item
 Make sure you are not running into an old bug by upgrading to the most recent
 version.
 @item
@@ -40674,6 +40712,7 @@ users uses this code as the rest of the code and because of this we are
 not yet 100 % confident in this code.
 
 @menu
+* News-3.23.33::                Changes in release 3.23.33
 * News-3.23.32::                Changes in release 3.23.32
 * News-3.23.31::                Changes in release 3.23.31
 * News-3.23.30::                Changes in release 3.23.30
@@ -40709,7 +40748,38 @@ not yet 100 % confident in this code.
 * News-3.23.0::                 Changes in release 3.23.0
 @end menu
 
-@node News-3.23.32, News-3.23.31, News-3.23.x, News-3.23.x
+@node News-3.23.33, News-3.23.32, News-3.23.x, News-3.23.x
+@appendixsubsec Changes in release 3.23.33
+@itemize bullet
+@item
+Fixed bug in replication that broke slave server start with existing
+@code{master.info} - bug introduced in 3.23.32
+@item
+Added @code{SET SQL_SLAVE_SKIP_COUNTER=n} command to recover from
+replication glitches without a full database copy
+@item
+Added @code{max_binlog_size} variable - binary log will be rotated
+automatically once the size crosses the limit.
+@item
+Added @code{Last_error}, @code{Last_errno}, and @code{Slave_skip_counter} to
+@code{SHOW SLAVE STATUS}.
+@item
+Fixed bug in @code{MASTER_POS_WAIT()} function.
+@item
+Execute coredump handler on @code{SIGILL}, and @code{SIGBUS} in addition to
+@code{SIGSEGV}.
+@item
+On x86 Linux, print the current query and thread (connection) id, if
+available, in the coredump handler.
+@item
+Fixed several timing bugs in the test suite
+@item
+Extended @code{mysqltest} to take care of the timing issues in the test
+suite.
+@end itemize
+
+
+@node News-3.23.32, News-3.23.31, News-3.23.33, News-3.23.x
 @appendixsubsec Changes in release 3.23.32
 @itemize @bullet
 @item

sql/mysqld.cc

@@ -1078,8 +1078,30 @@ static void init_signals(void)
 
 #ifdef HAVE_LINUXTHREADS
 static sig_handler write_core(int sig);
+
 #ifdef __i386__
 #define SIGRETURN_FRAME_COUNT  1
+#define PTR_SANE(p) ((char*)p >= heap_start && (char*)p <= heap_end)
+
+extern char* __bss_start;
+static char* heap_start, *heap_end;
+
+inline static __volatile__ void print_str(const char* name,
+					  const char* val, int max_len)
+{
+  fprintf(stderr, "%s at %p ", name, val);
+  if(!PTR_SANE(val))
+    {
+      fprintf(stderr, " is invalid pointer\n");
+      return;
+    }
+
+  fprintf(stderr, "= ");
+  for(; max_len && PTR_SANE(val) && *val; --max_len)
+    fputc(*val++, stderr);
+  fputc('\n', stderr);
+}
+
 inline static __volatile__ void  trace_stack()
 {
   uchar **stack_bottom;
@@ -1136,7 +1158,18 @@ New value of ebp failed sanity check terminating backtrace\n");
     ++frame_count;
   }
 
-  fprintf(stderr, "stack trace successful\n"); 
+  fprintf(stderr, "stack trace successful, now will try to get some\n\
+variables. Some pointers may be invalid and cause dump abort\n");
+  heap_start = __bss_start; 
+  heap_end = (char*)sbrk(0);
+  print_str("thd->query", thd->query, 1024);
+  fprintf(stderr, "thd->thread_id = %ld\n", thd->thread_id);
+  fprintf(stderr, "successfully dumped variables, if you ran with --log\n \
+take a look at the details of what thread %ld did to cause the crash.\n\
+In some cases of really bad corruption, this value can be invalid \n",
+	  thd->thread_id);
+  fprintf(stderr, "Please use the information above to create a repeatable\n\
+test case for the crash, and send it to bugs@lists.mysql.com\n");
 }
 #endif
 #endif
@@ -1195,6 +1228,8 @@ static void init_signals(void)
    sa.sa_handler=handle_segfault;
 #endif
   sigaction(SIGSEGV, &sa, NULL);
+  sigaction(SIGBUS, &sa, NULL);
+  sigaction(SIGILL, &sa, NULL);
   (void) sigemptyset(&set);
 #ifdef THREAD_SPECIFIC_SIGPIPE
   sigset(SIGPIPE,abort_thread);