Re: Possible Bug in UPdATE in MySQL 4.0.1 alpha
On Tue, 21 May 2002, Michael Widenius wrote: > > Hi! > > > "Michael" == Michael B Venezia <[EMAIL PROTECTED]> writes: > > >> Description: > Michael> Possible Bug in UPDATE in MySQL 4.0.1 > > > > Michael> Attempting backtrace. You can use the following information to find out > Michael> where mysqld died. If you see no messages after this, something went > Michael> terribly wrong... > Michael> Stack range sanity check OK, backtrace follows: > Michael> 0x807db7f > Michael> 0x823d64a > Michael> 0x8204447 > Michael> 0x821bbd6 > Michael> 0x820bb41 > Michael> 0x80d082f > Michael> 0x80b0479 > Michael> 0x8086de7 > Michael> 0x808a262 > Michael> 0x8084e57 > Michael> 0x808a694 > Michael> 0x8084296 > Michael> Stack trace seems successful - bottom reached > Michael> Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow > Michael> instructions on how to resolve the stack trace. Resolved > Michael> stack trace is much more helpful in diagnosing the problem, so please do > Michael> resolve it > > Michael, could you please read the above instructions and try to > resolve the backtrace for us? > > > > >> How-To-Repeat: > Michael> Did this query on a database called 'medical' below text > > Michael> UPDATE `Physical Examination Report` SET `History of Present > Michael> Illness`='moo\r\nfoo\r\nboo.' WHERE `ID Code of Appointment`=27 > > Any chance you could ftp a copy of the 'Physical Examination Report' > table to ftp://support.mysql.com/pub/mysql/secret > so that we could try to repeat the problem ? > > Just having the table definition formats is not enough to repeat a > problem like this! > > > > Regards, > Monty > I've uploaded the table as PhysicalExaminationReport.tar.gz to the above location. It is very small (actually it only contains one or two records if I recall) The following is the stack trace resolved... 0x807db7f handle_segfault__Fi + 383 0x823d64a pthread_sighandler + 154 0x8204447 _mi_compare_text + 71 0x821bbd6 _mi_ft_cmp + 158 0x820bb41 mi_update + 721 0x80d082f update_row__9ha_myisamPCcPc + 67 0x80b0479 mysql_update__FP3THDP13st_table_listRt4List1Z4ItemT2P4ItemP8st_orderUl15enum_duplicates13thr_lock_type + 2473 0x8086de7 mysql_execute_command__Fv + 5723 0x808a262 mysql_parse__FP3THDPcUi + 270 0x8084e57 dispatch_command__F19enum_server_commandP3THDPcUi + 1319 0x808a694 do_command__FP3THD + 88 0x8084296 handle_one_connection__FPv + 546 - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Possible Bug in UPdATE in MySQL 4.0.1 alpha
Hi! > "Michael" == Michael B Venezia <[EMAIL PROTECTED]> writes: >> Description: Michael>Possible Bug in UPDATE in MySQL 4.0.1 Michael> Attempting backtrace. You can use the following information to find out Michael> where mysqld died. If you see no messages after this, something went Michael> terribly wrong... Michael> Stack range sanity check OK, backtrace follows: Michael> 0x807db7f Michael> 0x823d64a Michael> 0x8204447 Michael> 0x821bbd6 Michael> 0x820bb41 Michael> 0x80d082f Michael> 0x80b0479 Michael> 0x8086de7 Michael> 0x808a262 Michael> 0x8084e57 Michael> 0x808a694 Michael> 0x8084296 Michael> Stack trace seems successful - bottom reached Michael> Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow Michael> instructions on how to resolve the stack trace. Resolved Michael> stack trace is much more helpful in diagnosing the problem, so please do Michael> resolve it Michael, could you please read the above instructions and try to resolve the backtrace for us? >> How-To-Repeat: Michael>Did this query on a database called 'medical' below text Michael>UPDATE `Physical Examination Report` SET `History of Present Michael> Illness`='moo\r\nfoo\r\nboo.' WHERE `ID Code of Appointment`=27 Any chance you could ftp a copy of the 'Physical Examination Report' table to ftp://support.mysql.com/pub/mysql/secret so that we could try to repeat the problem ? Just having the table definition formats is not enough to repeat a problem like this! Regards, Monty - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Possible Bug in UPdATE in MySQL 4.0.1 alpha
Michael, Sunday, May 19, 2002, 12:56:00 PM, you wrote: MBV> Description: MBV> Possible Bug in UPDATE in MySQL 4.0.1 MBV> The following is the message in the error log... MBV> Number of processes running now: 0 MBV> 020519 04:55:30 mysqld restarted MBV> 020519 4:55:30 InnoDB: Started MBV> /usr/local/mysql/bin/mysqld: ready for connections MBV> mysqld got signal 11; MBV> This could be because you hit a bug. It is also possible that this binary MBV> or one of the libraries it was linked against is corrupt, improperly MBV> built, MBV> or misconfigured. This error can also be caused by malfunctioning MBV> hardware. MBV> We will try our best to scrape up some info that will hopefully help MBV> diagnose MBV> the problem, but since we have already crashed, something is definitely MBV> wrong MBV> and this may fail. MBV> How-To-Repeat: MBV> Did this query on a database called 'medical' below text MBV> UPDATE `Physical Examination Report` SET `History of Present MBV> Illness`='moo\r\nfoo\r\nboo.' WHERE `ID Code of Appointment`=27 MBV> DUMP of medical database schema: MBV> This was done multiple times and caused the server to restart MBV> every time. MBV> Fix: MBV> Moved Database to a machine with MySQL 3.x (3.23.49) and the query MBV> worked without issue. I even tried this by simply copying the data MBV> directory over (tar.gz-ed the data directory, untared it on the other MBV> machine, and restarted the server) I tested you SQL statement and it works fine on my v4.0.1 Probably, SIG11 is cause by broken hardware. Please check it. BTW, if you use compound names for your tables and columns use --quote-names option of mysqldump. -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.net http://www.ensita.net/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Victoria Reznichenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.net <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Possible Bug in UPdATE in MySQL 4.0.1 alpha
>Description: Possible Bug in UPDATE in MySQL 4.0.1 The following is the message in the error log... Number of processes running now: 0 020519 04:55:30 mysqld restarted 020519 4:55:30 InnoDB: Started /usr/local/mysql/bin/mysqld: ready for connections mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402649088 record_buffer=268431360 sort_buffer=268435448 max_used_connections=0 max_connections=100 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 2489963 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Stack range sanity check OK, backtrace follows: 0x807db7f 0x823d64a 0x8204447 0x821bbd6 0x820bb41 0x80d082f 0x80b0479 0x8086de7 0x808a262 0x8084e57 0x808a694 0x8084296 Stack trace seems successful - bottom reached Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow instr uctions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x8423db0 = UPDATE `Physical Examination Report` SET `History of P resent Illness`='moo\r\nfoo\r\nboo.' WHERE `ID Code of Appointment`=27 thd->thread_id=7 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 7 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid. The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 020519 05:14:17 mysqld restarted 020519 5:14:17 InnoDB: Started /usr/local/mysql/bin/mysqld: ready for connections >How-To-Repeat: Did this query on a database called 'medical' below text UPDATE `Physical Examination Report` SET `History of Present Illness`='moo\r\nfoo\r\nboo.' WHERE `ID Code of Appointment`=27 DUMP of medical database schema: # phpMyAdmin MySQL-Dump # version 2.2.6 # http://phpwizard.net/phpMyAdmin/ # http://www.phpmyadmin.net/ (download page) # # Host: localhost # Generation Time: May 19, 2002 at 05:50 AM # Server version: 4.00.01 # PHP Version: 4.0.5 # Database : `medical` # # # Table structure for table `Appointment Types` # CREATE TABLE Appointment Types ( ID Code int(11) NOT NULL auto_increment, Description mediumtext NOT NULL, PRIMARY KEY (ID Code) ) TYPE=MyISAM COMMENT='Keeps Information unique to appointment type'; # # # Table structure for table `Appointments` # CREATE TABLE Appointments ( ID Code int(11) NOT NULL auto_increment, Date of Appointment date default NULL, ID Code of Patient int(11) default NULL, ID Code of Doctor int(11) default NULL, ID Code of Referer int(11) default NULL, ID Code of Second Referer int(11) default NULL, ID Code of Third Referer int(11) default NULL, ID Code of Fourth Referer int(11) default NULL, Type of Appointment int(11) default NULL, Complete int(11) default NULL, PRIMARY KEY (ID Code) ) TYPE=MyISAM COMMENT='Keeps track of what''s involved in the appointment'; # # # Table structure for table `Doctors` # CREATE TABLE Doctors ( ID Code int(11) NOT NULL auto_increment, First Name tinytext, Middle Name tinytext, Last Name tinytext, Initials tinytext, SSN tinytext, Business Street tinytext, Business City tinytext, Business State tinytext, Business Zip Code tinytext, Business Phone Number tinytext, Business Fax Number tinytext, Business Email Address tinytext, Home Street tinytext, Home City tinytext, Home State tinytext, Home Zip Code tinytext, Home Phone Number tinytext, Home Fax Number tinytext, Home Email Address tinytext, PRIMARY KEY (ID Code) ) TYPE=MyISAM COMMENT='Keeps important data concerning the physicians that work her'; # # # Table structure for table `Follow Up Report` # CREATE TABLE Follow Up Report ( Report Number int(11) NOT NULL auto_increment, ID Code of Appointment int(11) default NULL, ID Code of Patient int(11) default NULL, Date of Exam date default NULL, Date of Report
