Re: read_const error 127 - then MySQL dies
Richard, > thd->query at 0x89af670 = SELECT * FROM order_data WHERE viewed='' ORDER > BY order_num DESC what does SHOW CREATE TABLE order_data; say? What does CHECK TABLE order_data; say? Does it print anything to the .err log in the MySQL datadir? Please resolve the stack trace below: > Stack range sanity check OK, backtrace follows: > 0x80dbe1f > 0x4003b47e > 0x8101e09 > 0x810e90d > 0x80e6d8a > 0x80ea88b > 0x80e5ed3 > 0x80ebe0e > 0x80e50bf > 0x40035941 > 0x420da1ca > New value of fp=(nil) failed sanity check, terminating stack trace! > Please read http://www.mysql.com/doc/en/Using_stack_trace.html and > follow instructions on how to resolve the stack trace. Best regards, Heikki Tuuri Innobase Oy http://www.innodb.com Transactions, foreign keys, and a hot backup tool for MySQL Order MySQL technical support from https://order.mysql.com/ - Original Message - From: "Richard Gabriel" <[EMAIL PROTECTED]> Newsgroups: mailing.database.mysql Sent: Friday, August 08, 2003 11:50 PM Subject: read_const error 127 - then MySQL dies > Hi all, > > The following keeps happening and I can't pinpoint a query that is > causing it. It did not happen in 3.23.x, but started upon upgrading to > 4.0.14. The operating system/hardware information is as follows: > > RedHat 8.0 - kernel 2.4.18SMP > 4x Xeon Processors > 4x 80GB SCSI drives (hardware RAID-10) > 2GB RAM > > The following is a log exerpt: > > 030808 15:22:09 read_const: Got error 127 when reading table > 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=8388600 > read_buffer_size=131072 > max_used_connections=184 > max_connections=1000 > threads_connected=21 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections > = 2184184 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0x98772088 > 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... > Cannot determine thread, fp=0x98a4ad98, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x80dbe1f > 0x4003b47e > 0x8101e09 > 0x810e90d > 0x80e6d8a > 0x80ea88b > 0x80e5ed3 > 0x80ebe0e > 0x80e50bf > 0x40035941 > 0x420da1ca > New value of fp=(nil) failed sanity check, terminating stack trace! > Please read http://www.mysql.com/doc/en/Using_stack_trace.html and > follow instructions 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 0x89af670 = SELECT * FROM order_data WHERE viewed='' ORDER > BY order_num DESC > thd->thread_id=42660972 > The manual page at http://www.mysql.com/doc/en/Crashing.html contains > information that should help you find out what is causing the crash. > > Number of processes running now: 0 > 030808 15:22:19 mysqld restarted > 030808 15:22:20 InnoDB: Database was not shut down normally. > InnoDB: Starting recovery from log files... > InnoDB: Starting log scan based on checkpoint at > InnoDB: log sequence number 5 4012008225 > InnoDB: Doing recovery: scanned up to log sequence number 5 4012079335 > 030808 15:22:20 InnoDB: Starting an apply batch of log records to the > database... > InnoDB: Progress in percents: 31 32 33 34 35 36 37 38 39 40 41 42 43 44 > 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 > 69 70 71 72 73 74 75 > InnoDB: Apply batch completed > InnoDB: Last MySQL binlog file position 0 1058709429, file name > ./db1-bin.062 > 030808 15:22:21 InnoDB: Flushing modified pages from the buffer pool... > 030808 15:22:21 InnoDB: Started > /usr/sbin/mysqld-max: ready for connections. > Version: '4.0.14-Max-log' socket: '/var/lib/mysql/mysql.sock' port: > 3306 > > > This happens often. Any ideas? Thanks. > > -- > Richard Gabriel <[EMAIL PROTECTED]> > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: read_const error 127 - then MySQL dies
Richard, ok, in this case it is MyISAM table corruption. I have to classify this to the category 'unexplained corruption on a Red Hat 2.4.18 kernel'. Most corruption cases happen on those Linux kernels. My hypothesis is that some driver/hardware combinations are buggy. Since the corruption problem is random, any small change, like upgrading to MySQL-4.0.14, can make the bugs to surface. You can try upgrading to a Linux kernel 2.4.20. There are very few corruption reports from those kernels. You can also try converting the table to InnoDB. In 4.0.14 it contains a checksum which can help to prove the corruption problem really happens in the OS. Or, the corruption may disappear, because access patterns change slightly, and that may mask the bugs. Best regards, Heikki Innobase Oy http://www.innodb.com InnoDB - transactions, foreign keys, and a hot backup tool for MySQL Order MySQL support from http://www.mysql.com/support/index.html - Alkuperäinen viesti - Lähettäjä: "Richard Gabriel" <[EMAIL PROTECTED]> Vastaanottaja: "Heikki Tuuri" <[EMAIL PROTECTED]> Kopio: <[EMAIL PROTECTED]> Lähetetty: Monday, August 11, 2003 6:26 PM Aihe: Re: read_const error 127 - then MySQL dies > Please see below for the answers to your questions. I hope this helps > to diagnose the problem. Please let me know if you need any more > information as this seems to be happening to more and more people. > Thanks. > > On Sun, 2003-08-10 at 04:29, Heikki Tuuri wrote: > > Richard, > > > > > thd->query at 0x89af670 = SELECT * FROM order_data WHERE viewed='' ORDER > > > BY order_num DESC > > > > Also, a note about the above query: that query probably caused the > crash or had something to do with it, but I don't think that is the root > problem. I believe that an INSERT is causing the problem and since the > INSERT causes corruption, the SELECT doesn't work right. Sometimes the > server crashes and sometimes it doesn't. > > > what does > > > > SHOW CREATE TABLE order_data; > > > > say? > > > > CREATE TABLE `order_data` ( > `order_num` int(11) NOT NULL auto_increment, > `client_id` int(11) NOT NULL default '0', > `stamp` datetime NOT NULL default '-00-00 00:00:00', > `link_id` int(11) NOT NULL default '0', > `ship_first_name` varchar(128) NOT NULL default '', > `ship_last_name` varchar(200) NOT NULL default '', > `ship_address1` varchar(128) NOT NULL default '', > `ship_address2` varchar(128) NOT NULL default '', > `ship_city` varchar(128) NOT NULL default '', > `ship_state` varchar(4) NOT NULL default '', > `ship_zip` varchar(12) NOT NULL default '', > `ship_country` varchar(128) NOT NULL default '', > `ship_phone` varchar(64) NOT NULL default '', > `ship_business_phone` varchar(128) NOT NULL default '', > `ship_mobile_phone` varchar(32) NOT NULL default '', > `ship_fax` varchar(64) NOT NULL default '', > `ship_email` varchar(128) NOT NULL default '', > `ship_company` varchar(200) NOT NULL default '', > `bill_first_name` varchar(64) NOT NULL default '', > `bill_last_name` varchar(128) NOT NULL default '', > `bill_address1` varchar(200) NOT NULL default '', > `bill_address2` varchar(200) NOT NULL default '', > `bill_city` varchar(200) NOT NULL default '', > `bill_state` varchar(4) NOT NULL default '', > `bill_zip` varchar(16) NOT NULL default '', > `bill_country` varchar(128) NOT NULL default '', > `bill_phone` varchar(32) NOT NULL default '', > `bill_business_phone` varchar(32) NOT NULL default '', > `bill_mobile_phone` varchar(32) NOT NULL default '', > `bill_fax` varchar(32) NOT NULL default '', > `bill_email` varchar(128) NOT NULL default '', > `bill_company` varchar(128) NOT NULL default '', > `salesman` varchar(32) NOT NULL default '', > `ship_date` date NOT NULL default '-00-00', > `cc_type` tinyint(4) NOT NULL default '0', > `cc_number` varchar(128) NOT NULL default '', > `cc_exp_month` tinyint(4) NOT NULL default '0', > `cc_exp_year` tinyint(4) NOT NULL default '0', > `model_id` varchar(128) NOT NULL default '', > `extended_warranty` varchar(128) NOT NULL default '', > `shipping_cost` float(10,2) NOT NULL default '0.00', > `shipping_method` varchar(255) NOT NULL default '', > `quantity` tinyint
Re: read_const error 127 - then MySQL dies
` (`ship_first_name`(4)), KEY `ship_last_name` (`ship_last_name`(6)), KEY `bill_first_name` (`bill_first_name`(4)), KEY `bill_last_name` (`bill_last_name`(6)), KEY `ship_state` (`ship_state`(2)), KEY `bill_state` (`bill_state`(2)), KEY `viewed` (`viewed`(7)), KEY `order_status` (`order_status`) ) TYPE=MyISAM > What does > > CHECK TABLE order_data; > > say? Does it print anything to the .err log in the MySQL datadir? > The check says "ok" now, but the table was corrupted after the crash. I repaired it, but no messages were printed to the log. Usually a row is lost however and sometimes a message like this is found in the log: Note: Found 804 of 805 rows when repairing > Please resolve the stack trace below: > > > Stack range sanity check OK, backtrace follows: > > 0x80dbe1f > > 0x4003b47e > > 0x8101e09 > > 0x810e90d > > 0x80e6d8a > > 0x80ea88b > > 0x80e5ed3 > > 0x80ebe0e > > 0x80e50bf > > 0x40035941 > > 0x420da1ca > > New value of fp=(nil) failed sanity check, terminating stack trace! > > Please read http://www.mysql.com/doc/en/Using_stack_trace.html and > > follow instructions on how to resolve the stack trace. > resolve_stack_dump -s mysqld-max.sym -n mysql.stack 0x80dbe1f handle_segfault + 423 0x4003b47e _end + 934910594 0x8101e09 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UlP13select_result + 6937 0x810e90d handle_select__FP3THDP6st_lexP13select_result + 101 0x80e6d8a mysql_execute_command__Fv + 966 0x80ea88b mysql_parse__FP3THDPcUi + 559 0x80e5ed3 dispatch_command__F19enum_server_commandP3THDPcUi + 1471 0x80ebe0e do_command__FP3THD + 154 0x80e50bf handle_one_connection + 635 0x40035941 _end + 934887237 0x420da1ca _end + 969115598 > Best regards, > > Heikki Tuuri > Innobase Oy > http://www.innodb.com > Transactions, foreign keys, and a hot backup tool for MySQL > Order MySQL technical support from https://order.mysql.com/ > > > > - Original Message - > From: "Richard Gabriel" <[EMAIL PROTECTED]> > Newsgroups: mailing.database.mysql > Sent: Friday, August 08, 2003 11:50 PM > Subject: read_const error 127 - then MySQL dies > > > > Hi all, > > > > The following keeps happening and I can't pinpoint a query that is > > causing it. It did not happen in 3.23.x, but started upon upgrading to > > 4.0.14. The operating system/hardware information is as follows: > > > > RedHat 8.0 - kernel 2.4.18SMP > > 4x Xeon Processors > > 4x 80GB SCSI drives (hardware RAID-10) > > 2GB RAM > > > > The following is a log exerpt: > > > > 030808 15:22:09 read_const: Got error 127 when reading table > > 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=8388600 > > read_buffer_size=131072 > > max_used_connections=184 > > max_connections=1000 > > threads_connected=21 > > It is possible that mysqld could use up to > > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections > > = 2184184 K > > bytes of memory > > Hope that's ok; if not, decrease some variables in the equation. > > > > thd=0x98772088 > > 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... > > Cannot determine thread, fp=0x98a4ad98, backtrace may not be correct. > > Stack range sanity check OK, backtrace follows: > > 0x80dbe1f > > 0x4003b47e > > 0x8101e09 > > 0x810e90d > > 0x80e6d8a > > 0x80ea88b > > 0x80e5ed3 > > 0x80ebe0e > > 0x80e50bf > > 0x40035941 > > 0x420da1ca > > New value of fp=(nil) failed sanity check, terminating stack trace! > > Please read http://www.mysql.com/doc/en/Using_stack_trace.html and > > follow instructions 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 0x89af670 = SELECT * FROM order_data WHERE viewed='' ORDER > > BY order_num
read_const error 127 - then MySQL dies
Hi all, The following keeps happening and I can't pinpoint a query that is causing it. It did not happen in 3.23.x, but started upon upgrading to 4.0.14. The operating system/hardware information is as follows: RedHat 8.0 - kernel 2.4.18SMP 4x Xeon Processors 4x 80GB SCSI drives (hardware RAID-10) 2GB RAM The following is a log exerpt: 030808 15:22:09 read_const: Got error 127 when reading table 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=8388600 read_buffer_size=131072 max_used_connections=184 max_connections=1000 threads_connected=21 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2184184 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x98772088 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... Cannot determine thread, fp=0x98a4ad98, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80dbe1f 0x4003b47e 0x8101e09 0x810e90d 0x80e6d8a 0x80ea88b 0x80e5ed3 0x80ebe0e 0x80e50bf 0x40035941 0x420da1ca New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions 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 0x89af670 = SELECT * FROM order_data WHERE viewed='' ORDER BY order_num DESC thd->thread_id=42660972 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 030808 15:22:19 mysqld restarted 030808 15:22:20 InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 5 4012008225 InnoDB: Doing recovery: scanned up to log sequence number 5 4012079335 030808 15:22:20 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 1058709429, file name ./db1-bin.062 030808 15:22:21 InnoDB: Flushing modified pages from the buffer pool... 030808 15:22:21 InnoDB: Started /usr/sbin/mysqld-max: ready for connections. Version: '4.0.14-Max-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 This happens often. Any ideas? Thanks. -- Richard Gabriel <[EMAIL PROTECTED]> -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
MySQL dies when connecting via TCP/IP
I get this message in mysqld.log when trying to access the server via TCP/IP. When using sockets it works fine. Regards Michael Skaastrup - 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: MYSQL dies after FreeBSD 4.6.2-cvsup-4.7
Well, just a suggestion, but if you did not install world (where the threads are) then you have a mismatch between kernel and world. OT (but what the heck!) proper procedure for freebsd cvsup to desired version cd /usr/src mergemaster -p make buildworld make buildkernel KERNCONF=yourkernel make installkernel KERNCON=yourkernel reboot make installworld mergemaster (your favorite otpions eg: -i ) reboot once more. Have several server running 3.23 and 4.0 with no problems. Ken - Original Message - From: "Tuc" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, January 29, 2003 11:25 AM Subject: MYSQL dies after FreeBSD 4.6.2-cvsup-4.7 > Hi, > > We just cvsup'd a FreeBSD machine from 4.6.2 to 4.7, made world, > and installed a new kernel. Now mysql is complaining : > > > Fatal error 'Can't create gc thread' at line ? in file /usr/src/lib/libc_r/uthre > ad/uthread_create.c (errno = ?) > 030129 10:36:35 mysqld restarted > Fatal error 'Can't create gc thread' at line ? in file /usr/src/lib/libc_r/uthre > ad/uthread_create.c (errno = ?) > 030129 10:36:35 mysqld restarted > Fatal error 'Can't create gc thread' at line ? in file /usr/src/lib/libc_r/uthre > ad/uthread_create.c (errno = ?) > > > Any ideas where to start? Tried to recompile mysql to see if it just > needed that, and it didn't change anything. (This is 3.23.54a) > > Thanks, Tuc/TTSG Internet Services, Inc. > > > - > 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 > > - 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
MYSQL dies after FreeBSD 4.6.2-cvsup-4.7
Hi, We just cvsup'd a FreeBSD machine from 4.6.2 to 4.7, made world, and installed a new kernel. Now mysql is complaining : Fatal error 'Can't create gc thread' at line ? in file /usr/src/lib/libc_r/uthre ad/uthread_create.c (errno = ?) 030129 10:36:35 mysqld restarted Fatal error 'Can't create gc thread' at line ? in file /usr/src/lib/libc_r/uthre ad/uthread_create.c (errno = ?) 030129 10:36:35 mysqld restarted Fatal error 'Can't create gc thread' at line ? in file /usr/src/lib/libc_r/uthre ad/uthread_create.c (errno = ?) Any ideas where to start? Tried to recompile mysql to see if it just needed that, and it didn't change anything. (This is 3.23.54a) Thanks, Tuc/TTSG Internet Services, Inc. - 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: mysql dies at startup after upgrade form 3.23 to 4.0.3
jschleigh, Tuesday, October 01, 2002, 4:06:15 PM, you wrote: jahdc> I had a working install of mysql 3.23 in /usr/bin and /var/lib/mysql. I installed 4.0.3 to /usr/local/mysql and can't get it to run. I followed the installation instructions to the jahdc> T. When I run '/usr/local/mysql/bin/mysqld_safe&' I get: jahdc> Starting mysqld daemon with databases from /usr/local/mysql/data jahdc> 021001 08:53:00 mysqld ended jahdc> The old mysql still works fine (/usr/bin/safe_mysqld&). >How-To-Repeat: jahdc> I only have to try to run /usr/local/mysql/bin/mysqld_safe& to get the same results. Look at the error log file to see the causes of failed start. -- 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
mysql dies at startup after upgrade form 3.23 to 4.0.3
>Description: I had a working install of mysql 3.23 in /usr/bin and /var/lib/mysql. I installed 4.0.3 to /usr/local/mysql and can't get it to run. I followed the installation instructions to the T. When I run '/usr/local/mysql/bin/mysqld_safe&' I get: Starting mysqld daemon with databases from /usr/local/mysql/data 021001 08:53:00 mysqld ended The old mysql still works fine (/usr/bin/safe_mysqld&). >How-To-Repeat: I only have to try to run /usr/local/mysql/bin/mysqld_safe& to get the same results. >Fix: Not known >Submitter-Id: >Originator:[EMAIL PROTECTED] >Organization: >MySQL support: [none | licence | email support | extended email support ] >Synopsis: mysql dies when starting >Severity: critical >Priority: medium >Category: mysql >Class: support >Release: mysql-4.0.3-beta (Official MySQL binary) >Environment: Intel Celeron, SuSE 7.2 System: Linux freakshow 2.4.4-4GB #1 Fri May 18 14:11:12 GMT 2001 i686 unknown Architecture: i686 Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gmake /usr/local/bin/gcc /usr/bin/cc GCC: Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs Configured with: ./configure Thread model: posix gcc version 3.3 20020901 (experimental) Compilation info: CC='gcc' CFLAGS='-O2 -mcpu=pentiumpro ' CXX='gcc' CXXFLAGS='-O2 -mcpu=pentiumpro -felide-constructors' LDFLAGS='-static' LIBC: -rwxr-xr-x1 root root 1343073 May 11 2001 /lib/libc.so.6 -rw-r--r--1 root root 24539184 May 11 2001 /usr/lib/libc.a -rw-r--r--1 root root 178 May 11 2001 /usr/lib/libc.so Configure command: ./configure --prefix=/usr/local/mysql '--with-comment=Official MySQL binary' --with-extra-charsets=complex --with-server-suffix= --enable-thread-safe-client --enable-local-infile --enable-assembler --with-other-libc=/usr/local/mysql-glibc --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static --disable-shared 'CFLAGS=-O2 -mcpu=pentiumpro ' 'CXXFLAGS=-O2 -mcpu=pentiumpro -felide-constructors' CXX=gcc LDFLAGS=-static - 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
MySQL dies after longtext field created
My MySQL server 3.23.51 died in an hour after I created a table containing "longtext" field. I am not sure that this was the reason but suspect so since it was running for few weeks w/out problems. It stopped accepting answering TCP & UNIX socket connections, although was still listening on TCP. "killall mysqld" didn't stop it. During those kills it logged: Forcing close of thread 187 user: 'yuri' for several different thread numbers. Anyone knows if "longtext" functionality is still unstable so it shouldn't be used? Yuri. - 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: Mysql dies with Signal 11
On Saturday 23 February 2002 05:34 pm, you wrote: > (gdb) thread 1 > [Switching to thread 1 (process 31905, thread 1)] > #0 ?0x82011ce in memcpy () > (gdb) bt > #0 ?0x82011ce in memcpy () > #1 ?0x82a33c0 in mysql_bin_log () > #2 ?0x80b7cd8 in ha_commit_trans () > #3 ?0x8076e24 in mysql_execute_command () > #4 ?0x80788c8 in mysql_parse () > #5 ?0x8073454 in dispatch_command () > #6 ?0x80784c5 in do_command () > #7 ?0x80728f4 in handle_one_connection () > #8 ?0x81d446d in _thread_start () > #9 ?0x0 in ?? () Richard: Thanks for taking the time to debug this. This looks like there could be a bug in the binary logging on commit. It might be resolved in the current source or even in 4.0.1, but I will doublecheck that code to make sure. It would really help if you could come up with a repeatable test case and send it to [EMAIL PROTECTED] -- MySQL Development Team For technical support contracts, visit https://order.mysql.com/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA <___/ - 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: Mysql dies with Signal 11
Ok well the only reason I was using 4.0.0 is because I hadn't finished developing the application and figured I'd just leave what I installed at start before upgrading. I will install 4.0.1-max now and try that out and if I have further problems I will let you know. All my tables are innodb and for future reference, here is my my.cnf # The MySQL server [mysqld] port= 3306 socket = /tmp/mysql.sock skip-locking set-variable= key_buffer=256M set-variable= max_allowed_packet=1M set-variable= table_cache=256 set-variable= sort_buffer=1M set-variable= record_buffer=1M set-variable= myisam_sort_buffer_size=64M set-variable= thread_cache=8 set-variable= max_binlog_size=2097152 # Try number of CPU's*2 for thread_concurrency set-variable= thread_concurrency=8 log-bin server-id = 1 # Uncomment the following if you are using BDB tables #set-variable = bdb_cache_size=64M #set-variable = bdb_max_lock=10 # Uncomment the following if you are using Innobase tables innodb_data_file_path = ibdata/ibdata1:4000M innodb_data_home_dir = /usr/local/mysql/var/ innodb_log_group_home_dir = /usr/local/mysql/var/ innodb_log_arch_dir = /usr/local/mysql/var/ set-variable = innodb_mirrored_log_groups=1 set-variable = innodb_log_files_in_group=3 set-variable = innodb_log_file_size=5M set-variable = innodb_log_buffer_size=8M innodb_flush_log_at_trx_commit=1 innodb_log_archive=0 set-variable = innodb_buffer_pool_size=100M set-variable = innodb_additional_mem_pool_size=20M set-variable = innodb_file_io_threads=4 set-variable = innodb_lock_wait_timeout=50 Richard - Original Message - From: "Heikki Tuuri" <[EMAIL PROTECTED]> To: ""Richard Clarke"" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, February 24, 2002 5:32 PM Subject: Re: Mysql dies with Signal 11 > Richard, > > >(gdb) thread 1 > >[Switching to thread 1 (process 31905, thread 1)] > >#0 0x82011ce in memcpy () > >(gdb) bt > >#0 0x82011ce in memcpy () > >#1 0x82a33c0 in mysql_bin_log () > >#2 0x80b7cd8 in ha_commit_trans () > >#3 0x8076e24 in mysql_execute_command () > >#4 0x80788c8 in mysql_parse () > >#5 0x8073454 in dispatch_command () > >#6 0x80784c5 in do_command () > >#7 0x80728f4 in handle_one_connection () > >#8 0x81d446d in _thread_start () > >#9 0x0 in ?? () > > looks like mysqld crashed when it was writing to the MySQL binlog. > > If you can repeat the crash easily, please do > > CFLAGS="-g" CXXFLAGS="-g" ./configure --with-innodb > > gmake > > so that you get a mysqld binary with the debug info compiled in. Then run > mysqld inside gdb, and do > > gdb>bt full > > when it crashes. Also do 'bt full' for other 'interesting' threads than the > one which crashed. > > What is your my.cnf like? What table types you use? > > Lots of bugs have been fixed since 4.0.0, but I did not notice anything > connected to the binlog. When Monty gets back from the Galapagos Islands on > March 4, he will start building 4.0.2. > > Why do you run 4.0? 3.23.49 might be a safer bet. What FreeBSD version you > run? What threads you use? There are problems with some thread > implementations in FreeBSD. > > Best regards, > > Heikki Tuuri > Innobase Oy > --- > Order technical MySQL/InnoDB support at https://order.mysql.com/ > See http://www.innodb.com for the online manual and latest news on InnoDB > > > -Original Message- > From: "Richard Clarke" <[EMAIL PROTECTED]> > Newsgroups: mailing.database.mysql > Date: Sunday, February 24, 2002 2:42 AM > Subject: Mysql dies with Signal 11 > > > >Hi, > >I seem to be getting intermittant crashes of mysql. The error log > prints > >the following, > > > >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=268431360 > >record_buffer=1044480 > >sort_buffer=1048568 > >max_used_connections=5 > >max_connections=100 > >threads_connected=5 > >It is possible that mysqld could use up to > >key_buffer_size + (record_buffer + sort_buffer)*max_connections = 466539 K > >bytes of memory > >Hope that's ok; if not, decrease some variables in the equation. > >
Re: Mysql dies with Signal 11
Richard, >(gdb) thread 1 >[Switching to thread 1 (process 31905, thread 1)] >#0 0x82011ce in memcpy () >(gdb) bt >#0 0x82011ce in memcpy () >#1 0x82a33c0 in mysql_bin_log () >#2 0x80b7cd8 in ha_commit_trans () >#3 0x8076e24 in mysql_execute_command () >#4 0x80788c8 in mysql_parse () >#5 0x8073454 in dispatch_command () >#6 0x80784c5 in do_command () >#7 0x80728f4 in handle_one_connection () >#8 0x81d446d in _thread_start () >#9 0x0 in ?? () looks like mysqld crashed when it was writing to the MySQL binlog. If you can repeat the crash easily, please do CFLAGS="-g" CXXFLAGS="-g" ./configure --with-innodb gmake so that you get a mysqld binary with the debug info compiled in. Then run mysqld inside gdb, and do gdb>bt full when it crashes. Also do 'bt full' for other 'interesting' threads than the one which crashed. What is your my.cnf like? What table types you use? Lots of bugs have been fixed since 4.0.0, but I did not notice anything connected to the binlog. When Monty gets back from the Galapagos Islands on March 4, he will start building 4.0.2. Why do you run 4.0? 3.23.49 might be a safer bet. What FreeBSD version you run? What threads you use? There are problems with some thread implementations in FreeBSD. Best regards, Heikki Tuuri Innobase Oy --- Order technical MySQL/InnoDB support at https://order.mysql.com/ See http://www.innodb.com for the online manual and latest news on InnoDB -Original Message- From: "Richard Clarke" <[EMAIL PROTECTED]> Newsgroups: mailing.database.mysql Date: Sunday, February 24, 2002 2:42 AM Subject: Mysql dies with Signal 11 >Hi, >I seem to be getting intermittant crashes of mysql. The error log prints >the following, > >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=268431360 >record_buffer=1044480 >sort_buffer=1048568 >max_used_connections=5 >max_connections=100 >threads_connected=5 >It is possible that mysqld could use up to >key_buffer_size + (record_buffer + sort_buffer)*max_connections = 466539 K >bytes of memory >Hope that's ok; if not, decrease some variables in the equation. > >020223 13:00:01 mysqld restarted >InnoDB: Database was not shut down normally. >InnoDB: Starting recovery from log files... >InnoDB: Starting log scan based on checkpoint at >InnoDB: log sequence number 82 1555315003 >etc... > >Can some please suggest what steps I can take to discovering what is wrong. >I have attached server info and gdb output to bottom of email. >This is a very active server processing 150 apache hits a second. A seperate >looped process takes cgi data inserted into an IPC MSGQ and sticks it in the >db and another seperate looped process takes data from this db and dumps to >a db on a remote machine. > > >Richard > >p.s. >Your MySQL connection id is 7 to server version: 4.0.0-alpha-log >I'm running a dual 1ghz FreeBSD box with 1gig of ram. > >(gdb) run -u mysql >Starting program: /usr/local/mysql/libexec/mysqld -u mysql >020223 14:09:16 InnoDB: Started >/usr/local/mysql/libexec/mysqld: ready for connections > >(after about 8hrs.) >Program received signal SIGSEGV, Segmentation fault. >0x82011ce in memcpy () > >(gdb) info threads > 14 process 31905, thread 14 0x81df52d in _thread_kern_sched () > 13 process 31905, thread 13 0x81df52d in _thread_kern_sched () > 12 process 31905, thread 12 0x81df52d in _thread_kern_sched () > 11 process 31905, thread 11 0x81df52d in _thread_kern_sched () > 10 process 31905, thread 10 0x81df52d in _thread_kern_sched () > 9 process 31905, thread 9 0x81df52d in _thread_kern_sched () > 8 process 31905, thread 8 0x81df52d in _thread_kern_sched () > 7 process 31905, thread 7 0x81df52d in _thread_kern_sched () > 6 process 31905, thread 6 0x81df52d in _thread_kern_sched () > 5 process 31905, thread 5 0x81df52d in _thread_kern_sched () > 4 process 31905, thread 4 0x81df52d in _thread_kern_sched () > 3 process 31905, thread 3 0x82013dc in _thread_sys_close () > 2 process 31905, thread 2 0x81df52d in _thread_kern_sched () >* 1 process 31905, thread 1 0x82011ce in memcpy () > >(gdb) thread 1 >[Switching to thread 1 (process 31905, thread 1)] >#0 0x82011ce in memcpy () >(gdb) bt >#0 0x82011ce in memcpy () >#1 0x82a33c0 in mysql_bin_log () >
Mysql dies with Signal 11
Hi, I seem to be getting intermittant crashes of mysql. The error log prints the following, 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=268431360 record_buffer=1044480 sort_buffer=1048568 max_used_connections=5 max_connections=100 threads_connected=5 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 466539 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. 020223 13:00:01 mysqld restarted InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 82 1555315003 etc... Can some please suggest what steps I can take to discovering what is wrong. I have attached server info and gdb output to bottom of email. This is a very active server processing 150 apache hits a second. A seperate looped process takes cgi data inserted into an IPC MSGQ and sticks it in the db and another seperate looped process takes data from this db and dumps to a db on a remote machine. Richard p.s. Your MySQL connection id is 7 to server version: 4.0.0-alpha-log I'm running a dual 1ghz FreeBSD box with 1gig of ram. (gdb) run -u mysql Starting program: /usr/local/mysql/libexec/mysqld -u mysql 020223 14:09:16 InnoDB: Started /usr/local/mysql/libexec/mysqld: ready for connections (after about 8hrs.) Program received signal SIGSEGV, Segmentation fault. 0x82011ce in memcpy () (gdb) info threads 14 process 31905, thread 14 0x81df52d in _thread_kern_sched () 13 process 31905, thread 13 0x81df52d in _thread_kern_sched () 12 process 31905, thread 12 0x81df52d in _thread_kern_sched () 11 process 31905, thread 11 0x81df52d in _thread_kern_sched () 10 process 31905, thread 10 0x81df52d in _thread_kern_sched () 9 process 31905, thread 9 0x81df52d in _thread_kern_sched () 8 process 31905, thread 8 0x81df52d in _thread_kern_sched () 7 process 31905, thread 7 0x81df52d in _thread_kern_sched () 6 process 31905, thread 6 0x81df52d in _thread_kern_sched () 5 process 31905, thread 5 0x81df52d in _thread_kern_sched () 4 process 31905, thread 4 0x81df52d in _thread_kern_sched () 3 process 31905, thread 3 0x82013dc in _thread_sys_close () 2 process 31905, thread 2 0x81df52d in _thread_kern_sched () * 1 process 31905, thread 1 0x82011ce in memcpy () (gdb) thread 1 [Switching to thread 1 (process 31905, thread 1)] #0 0x82011ce in memcpy () (gdb) bt #0 0x82011ce in memcpy () #1 0x82a33c0 in mysql_bin_log () #2 0x80b7cd8 in ha_commit_trans () #3 0x8076e24 in mysql_execute_command () #4 0x80788c8 in mysql_parse () #5 0x8073454 in dispatch_command () #6 0x80784c5 in do_command () #7 0x80728f4 in handle_one_connection () #8 0x81d446d in _thread_start () #9 0x0 in ?? () (gdb) thread 2 [Switching to thread 2 (process 31905, thread 2)] #0 0x81df52d in _thread_kern_sched () (gdb) bt #0 0x81df52d in _thread_kern_sched () #1 0x81dfdb7 in _thread_kern_sched_state () #2 0x81dd4fc in _read () #3 0x81dd56a in read () #4 0x81ad019 in vio_read () #5 0x806945b in my_real_read () #6 0x806973e in my_net_read () #7 0x80784a8 in do_command () #8 0x80728f4 in handle_one_connection () #9 0x81d446d in _thread_start () #10 0x0 in ?? () (gdb) thread 3 [Switching to thread 3 (process 31905, thread 3)] #0 0x82013dc in _thread_sys_close () (gdb) bt #0 0x82013dc in _thread_sys_close () Error accessing memory address 0xe2fa6fd4: Bad address. (gdb) thread 4 [Switching to thread 4 (process 31905, thread 4)] #0 0x81df52d in _thread_kern_sched () (gdb) bt #0 0x81df52d in _thread_kern_sched () #1 0x81dfdb7 in _thread_kern_sched_state () #2 0x81dd4fc in _read () #3 0x81dd56a in read () #4 0x81ad019 in vio_read () #5 0x806945b in my_real_read () #6 0x806973e in my_net_read () #7 0x80784a8 in do_command () #8 0x80728f4 in handle_one_connection () #9 0x81d446d in _thread_start () #10 0x0 in ?? () (gdb) thread 5 [Switching to thread 5 (process 31905, thread 5)] #0 0x81df52d in _thread_kern_sched () (gdb) bt #0 0x81df52d in _thread_kern_sched () #1 0x81dfdb7 in _thread_kern_sched_state () #2 0x81d3802 in sigwait () #3 0x806dc25 in signal_hand () #4 0x81d446d in _thread_start () #5 0x0 in ?? () (gdb) thread 6 [Switching to thread 6 (process 31905, thread 6)] #0 0x81df52d in _thread_kern_sched () (gdb) bt #0 0x81df52d in _thread_kern_sched () #1 0x81dfdb7 in _thread_kern_sched_state () #2 0x81dd29f in select () #3 0x817ab38 in os_thread_sleep () #4 0x80de4f6 in srv_master_thread () #5 0x81d446d in _thread_
RE: MySQL dies
You might want to increase your max_connections using : -O max_connections=1000 as an option in mysqld_safe. See http://www.mysql.com/doc/S/e/Server_parameters.html for more information. -Original Message- From: "Müller, Markus" [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 8:00 AM To: '[EMAIL PROTECTED]' Subject: MySQL dies Hi, I'm in desperate need of help. MySQL keeps dying and I just can't figure out why... Here goes: Clients connect from Windows machines via VB and Delphi apps through myodbc doing queries on databases with *big* tables containing over 1.6 million records Often they're losing connection because mysql dies, queries have to be done again. Error log says that mysqld restarted, i.e. safe_mysqld immediately restarts the server. Only mysql is running on the machine. Queries may look like this: CREATE TEMPORARY TABLE tmpTable(FRM varchar(5),ARKL varchar(5),KNR varchar(10),ZWT float(11,5),VPN float(11,5),GRS varchar(32),MNG float(11,5),BRW float(11,5), NTW float(11,5)); INSERT INTO tmpTable(FRM,ARKL,KNR,ZWT,VPN,GRS,MNG,BRW, NTW)SELECT left(MNR,5),right(MNR,5),KNR,ZWT/MNG,VPN,substring_index(GRS,'X',1)* right(substring_index(GRS,'X',2),length(substring_index(GRS,'X',2))-length(s ubstring_index(GRS,'X',1))-1)* right(GRS,length(GRS)-length(substring_index(GRS,'X',2))-1)/1000,MNG,BRW,NTW FROM MASTER WHERE (BLDAT >= 20010901 AND BLT <= 20011231 AND SRT = '04' AND SRT = '06') MASTER is one *big* table containing 1.6 Million records... Info on the system: netbsd 1.5.2, 512 mb RAM mysql --version mysql Ver 11.13 Distrib 3.23.35, for -netbsd (i386) mysqladmin variables: +-+- --+ | Variable_name | Value | +-+- --+ | ansi_mode | OFF | | back_log| 50 | | basedir | /usr/pkg/ | | binlog_cache_size | 32768 | | character_set | latin1 | | character_sets | latin1 dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek win1250 croat cp1257 latin5 | | concurrent_insert | ON | | connect_timeout | 10 | | datadir | /usr/var/mysql/ | | delay_key_write | ON | | delayed_insert_limit| 100 | | delayed_insert_timeout | 300 | | delayed_queue_size | 1000 | | flush | OFF | | flush_time | 0 | | have_bdb| NO | | have_gemini | NO | | have_innobase | NO | | have_isam | YES | | have_raid | NO | | have_ssl| NO | | init_file | | | interactive_timeout | 28800 | | join_buffer_size| 131072 | | key_buffer_size | 16773120 | | language| /usr/pkg/share/mysql/english/ | | large_files_support | ON | | locked_in_memory| OFF | | log | ON | | log_update | OFF | | log_bin | OFF | | log_slave_updates | OFF | | long_query_time | 10 | | low_priority_updates| OFF | | lower_case_table_names | 0 | | max_allowed_packet | 1047552 | | max_binlog_cache_size | 4294967295 | | max_binlog_size | 1073741824 | | max_connections | 100 | | max_connect_errors | 10 | | max_delayed_threads | 20 | | max_heap_table_size | 16777216 | | max_join_size | 4294967295 | | max_sort_length | 1024 | | max_user_connections| 0 | | max_tmp_tables | 32 | | max_write_lock_count| 4294967295 | | myisam_recover_options | OFF | | myisam_sort_buffer_size | 8388608 | | net_buffer_length | 7168 | | net_read_timeout| 120 | | net_retry_count | 40 | | net_write_timeout | 240 | | open_files_limit| 0 | | pid_file| /usr/var/mysql/unixtest.pid | | port| 3306 | | protocol_version| 10 | | record_buffer | 131072 | | query_buffer_size | 1044480 | | safe_show_database | OFF | | server_id | 1 | | skip_locking| ON | | skip_networking | OFF | | skip_show_database | OFF | | slow_launch_time| 2 | | socket | /tmp/mysql.sock | | sort_buffer | 524280 | | table_cache | 64 | | table_type | MYISAM | | thread_cache_size | 0 | | thread_stack| 65536 | | timezone| CET | | tmp_table_size | 1048576 | | tmp
MySQL dies
Hi, I'm in desperate need of help. MySQL keeps dying and I just can't figure out why... Here goes: Clients connect from Windows machines via VB and Delphi apps through myodbc doing queries on databases with *big* tables containing over 1.6 million records Often they're losing connection because mysql dies, queries have to be done again. Error log says that mysqld restarted, i.e. safe_mysqld immediately restarts the server. Only mysql is running on the machine. Queries may look like this: CREATE TEMPORARY TABLE tmpTable(FRM varchar(5),ARKL varchar(5),KNR varchar(10),ZWT float(11,5),VPN float(11,5),GRS varchar(32),MNG float(11,5),BRW float(11,5), NTW float(11,5)); INSERT INTO tmpTable(FRM,ARKL,KNR,ZWT,VPN,GRS,MNG,BRW, NTW)SELECT left(MNR,5),right(MNR,5),KNR,ZWT/MNG,VPN,substring_index(GRS,'X',1)* right(substring_index(GRS,'X',2),length(substring_index(GRS,'X',2))-length(s ubstring_index(GRS,'X',1))-1)* right(GRS,length(GRS)-length(substring_index(GRS,'X',2))-1)/1000,MNG,BRW,NTW FROM MASTER WHERE (BLDAT >= 20010901 AND BLT <= 20011231 AND SRT = '04' AND SRT = '06') MASTER is one *big* table containing 1.6 Million records... Info on the system: netbsd 1.5.2, 512 mb RAM mysql --version mysql Ver 11.13 Distrib 3.23.35, for -netbsd (i386) mysqladmin variables: +-+- --+ | Variable_name | Value | +-+- --+ | ansi_mode | OFF | | back_log| 50 | | basedir | /usr/pkg/ | | binlog_cache_size | 32768 | | character_set | latin1 | | character_sets | latin1 dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek win1250 croat cp1257 latin5 | | concurrent_insert | ON | | connect_timeout | 10 | | datadir | /usr/var/mysql/ | | delay_key_write | ON | | delayed_insert_limit| 100 | | delayed_insert_timeout | 300 | | delayed_queue_size | 1000 | | flush | OFF | | flush_time | 0 | | have_bdb| NO | | have_gemini | NO | | have_innobase | NO | | have_isam | YES | | have_raid | NO | | have_ssl| NO | | init_file | | | interactive_timeout | 28800 | | join_buffer_size| 131072 | | key_buffer_size | 16773120 | | language| /usr/pkg/share/mysql/english/ | | large_files_support | ON | | locked_in_memory| OFF | | log | ON | | log_update | OFF | | log_bin | OFF | | log_slave_updates | OFF | | long_query_time | 10 | | low_priority_updates| OFF | | lower_case_table_names | 0 | | max_allowed_packet | 1047552 | | max_binlog_cache_size | 4294967295 | | max_binlog_size | 1073741824 | | max_connections | 100 | | max_connect_errors | 10 | | max_delayed_threads | 20 | | max_heap_table_size | 16777216 | | max_join_size | 4294967295 | | max_sort_length | 1024 | | max_user_connections| 0 | | max_tmp_tables | 32 | | max_write_lock_count| 4294967295 | | myisam_recover_options | OFF | | myisam_sort_buffer_size | 8388608 | | net_buffer_length | 7168 | | net_read_timeout| 120 | | net_retry_count | 40 | | net_write_timeout | 240 | | open_files_limit| 0 | | pid_file| /usr/var/mysql/unixtest.pid | | port| 3306 | | protocol_version| 10 | | record_buffer | 131072 | | query_buffer_size | 1044480 | | safe_show_database | OFF | | server_id | 1 | | skip_locking| ON | | skip_networking | OFF | | skip_show_database | OFF | | slow_launch_time| 2 | | socket | /tmp/mysql.sock | | sort_buffer | 524280 | | table_cache | 64 | | table_type | MYISAM | | thread_cache_size | 0 | | thread_stack| 65536 | | timezone| CET | | tmp_table_size | 1048576 | | tmpdir | /var/tmp/ | | version | 3.23.35-log | | wait_timeout| 115200 | +-+- --+ | core dumps available... (they're BIG -21M) Help is very much appreciated... Marc ---
Mysql dies on signal 11
>Description: Mysql dies in signal 11 >How-To-Repeat: Don't know. Seems to happen when machine runs for more than 24 hours. >Fix: Unknown. We will be trying the latest version of Mysql (3.23.46). >Submitter-Id: [EMAIL PROTECTED] >Originator:Petro >Organization: Auctionwatch.com, Operations Department. >MySQL support: login level. >Synopsis: Mysql dies on signal 11 >Severity: critical >Priority: high >Category: mysql >Class: sw-bug >Release: mysql-3.23.43 (Official MySQL binary) >Environment: VALinux Fullon 2230, 2x600Mhz CPU, 2 Gig ram, 4x75 gig drives attached in a raid 0 config via a 3ware 6400, 1x34 gig scsi drive attached via onboard scsi controler as boot/root/log volume. Debian variant of Linux running kernel 2.4.16. System: Linux dbraux01-red.auctionwatch.com 2.4.16 #1 SMP Wed Dec 12 17:16:00 PST 2001 i686 unknown Architecture: i686 Some paths: /usr/bin/perl /usr/bin/make Compilation info: CC='gcc' CFLAGS='-O3 -mpentium ' CXX='gcc' CXXFLAGS='-O3 -mpentium -felide-constructors' LDFLAGS='-static' LIBC: lrwxrwxrwx1 root root 13 Dec 11 15:23 /lib/libc.so.6 -> libc-2.2.3.so -rwxr-xr-x1 root root 1155720 Jul 27 13:42 /lib/libc-2.2.3.so -rw-r--r--1 root root 2579358 Jul 25 08:15 /usr/lib/libc.a -rw-r--r--1 root root 178 Jul 25 08:15 /usr/lib/libc.so Configure command: ./configure --prefix=/usr/local/mysql '--with-comment=Official MySQL binary' --with-extra-charsets=complex --with-server-suffix= --enable-assembler --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static --disable-shared We have experienced a similar crashes across 3 instances of this environment. - 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
mySQL dies on win98
I am using my laptop running win98 to develop a php site using Apache/mySQL. Inevitably, after working for about 45min-60min, I can no longer connect to mySQL, and apache will no longer refresh the pages properly. At this point, restarting the mySQL server and Apache does not do any good. The only solution is to re-boot the machine. This is not critical as it's only my own development environment, but it's rather annoying. I can't run Linux on my laptop yet because I have not had the time to troubleshoot my pcmcia network card installation, and so I'm stuck on win98 for a while. Has anyone out there encountered this sort of behavior, and is there a solution for it? thanks! Philippe Paravicini eCommerce Developer - 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
Mysql dies
Hi, When trying to run mysql I get the message 'found old style password for user 'graham' . Restart using --old-protocol' How can I cure this problem please? I tried running mysql --old-protocol without success. Many thanks, Graham
Re: MySQL dies, fails to restart (address already in use)
[EMAIL PROTECTED] writes: > >Description: > > After running for a variable amount of time, our server will just die. > We have run myisamchk several times, with -r and with -o. We even > checked the actual file system for corruption. This is a real problem > when the server doesn't automatically restart. > > This is what the log looks like when it doesn't come back up: > > mysqld got signal 11; > > The manual section 'Debugging a MySQL server' tells you how to use a > > stack trace and/or the core file to produce a readable backtrace that may > > help in finding out why mysqld died > > Attemping backtrace. You can use the following information to find out > > where mysqld died. If you see no messages after this, something went > > terribly wrong > > Bogus stack limit or frame pointer, aborting backtrace > > > > Number of processes running now: 0 > > 010209 18:37:25 mysqld restarted > > 010209 18:37:25 Can't start server: Bind on TCP/IP port: Address already > > in use > > 010209 18:37:25 Do you already have another mysqld server running on > > port: 1433 ? > > 010209 18:37:25 Aborting > > > > 010209 18:37:25 mysqld ended > > > > >Severity: serious > >Priority: high > >Category: mysql > >Class: > >Release:mysql-3.23.32 (Official MySQL RPM) > >Server: /usr/bin/mysqladmin Ver 8.14 Distrib 3.23.32, for pc-linux-gnu on i686 > Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB > This software comes with ABSOLUTELY NO WARRANTY. This is free software, > and you are welcome to modify and redistribute it under the GPL license > > Server version 3.23.32 > Protocol version 10 > Connection Localhost via UNIX socket > UNIX socket /var/lib/mysql/mysql.sock > Uptime: 4 min 19 sec > > Threads: 101 Questions: 255072 Slow queries: 0 Opens: 139 Flush tables: 1 Open >tables: 133 Queries per second avg: 984.834 > >Environment: > > System: Linux db1.audiogalaxy.com 2.4.2-pre3 #1 SMP Fri Feb 9 18:01:57 CST 2001 i686 >unknown > Architecture: i686 > > Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc /usr/bin/cc > GCC: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs > gcc version 2.96 2731 (Red Hat Linux 7.0) > Compilation info: CC='egcs' CFLAGS='-O6 -fomit-frame-pointer -mpentium' CXX='egcs' > CXXFLAGS='-O6 -fomit-frame-pointer -felide-constructors >-fno-exceptions -fno-rtti -mpentium' LDFLAGS='' > LIBC: > lrwxrwxrwx1 root root 14 Dec 18 04:16 /lib/libc.so.6 -> >libc-2.1.94.so > -rwxr-xr-x1 root root 4796386 Oct 5 16:46 /lib/libc-2.1.94.so > -rw-r--r--1 root root 22737326 Oct 5 16:09 /usr/lib/libc.a > -rw-r--r--1 root root 178 Oct 5 16:09 /usr/lib/libc.so > Configure command: ./configure --disable-shared --with-mysqld-ldflags=-all-static >--with-client-ldflags=-all-static --enable-assembler --with-mysqld-user=mysql >--with-unix-socket-path=/var/lib/mysql/mysql.sock --prefix=/ >--with-extra-charsets=complex --exec-prefix=/usr --libexecdir=/usr/sbin >--sysconfdir=/etc --datadir=/usr/share --localstatedir=/var/lib/mysql >--infodir=/usr/info --includedir=/usr/include --mandir=/usr/man --without-berkeley-db >'--with-comment=Official MySQL RPM' Hi! Our binaries are built on 2.2 kernel. Please try to upgrade your glibc to 2.2 and try building mysql yourself. Regards, Sinisa __ _ _ ___ == MySQL AB /*/\*\/\*\ /*/ \*\ /*/ \*\ |*| Sinisa Milivojevic /*/ /*/ /*/ \*\_ |*| |*||*|
MySQL dies, fails to restart (address already in use)
>Description: After running for a variable amount of time, our server will just die. We have run myisamchk several times, with -r and with -o. We even checked the actual file system for corruption. This is a real problem when the server doesn't automatically restart. This is what the log looks like when it doesn't come back up: mysqld got signal 11; The manual section 'Debugging a MySQL server' tells you how to use a stack trace and/or the core file to produce a readable backtrace that may help in finding out why mysqld died Attemping backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong Bogus stack limit or frame pointer, aborting backtrace Number of processes running now: 0 010209 18:37:25 mysqld restarted 010209 18:37:25 Can't start server: Bind on TCP/IP port: Address already in use 010209 18:37:25 Do you already have another mysqld server running on port: 1433 ? 010209 18:37:25 Aborting 010209 18:37:25 mysqld ended >Severity: serious >Priority: high >Category: mysql >Class: >Release: mysql-3.23.32 (Official MySQL RPM) >Server: /usr/bin/mysqladmin Ver 8.14 Distrib 3.23.32, for pc-linux-gnu on i686 Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL license Server version 3.23.32 Protocol version10 Connection Localhost via UNIX socket UNIX socket /var/lib/mysql/mysql.sock Uptime: 4 min 19 sec Threads: 101 Questions: 255072 Slow queries: 0 Opens: 139 Flush tables: 1 Open tables: 133 Queries per second avg: 984.834 >Environment: System: Linux db1.audiogalaxy.com 2.4.2-pre3 #1 SMP Fri Feb 9 18:01:57 CST 2001 i686 unknown Architecture: i686 Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc /usr/bin/cc GCC: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.0) Compilation info: CC='egcs' CFLAGS='-O6 -fomit-frame-pointer -mpentium' CXX='egcs' CXXFLAGS='-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -mpentium' LDFLAGS='' LIBC: lrwxrwxrwx1 root root 14 Dec 18 04:16 /lib/libc.so.6 -> libc-2.1.94.so -rwxr-xr-x1 root root 4796386 Oct 5 16:46 /lib/libc-2.1.94.so -rw-r--r--1 root root 22737326 Oct 5 16:09 /usr/lib/libc.a -rw-r--r--1 root root 178 Oct 5 16:09 /usr/lib/libc.so Configure command: ./configure --disable-shared --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static --enable-assembler --with-mysqld-user=mysql --with-unix-socket-path=/var/lib/mysql/mysql.sock --prefix=/ --with-extra-charsets=complex --exec-prefix=/usr --libexecdir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --localstatedir=/var/lib/mysql --infodir=/usr/info --includedir=/usr/include --mandir=/usr/man --without-berkeley-db '--with-comment=Official MySQL RPM' - 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