MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Ugo Bellavance Date:November 4 2004 7:29pm
Subject:4.1.7 serious problems
View as plain text  
Hi,

	I've upgraded one of my servers (test) to 4.1.7 this week, all went ok. 
  Now I'm trying to upgrade another server (production) from 4.1.3 to 
4.1.7 and I'm having serious problems.  I tried 4.1.6 as well, same problem.

OS: Tao Linux (Red Hat Enterprise Linux 3.0 clone).

	First, since I couldn't find a procedure saying how to upgrade a 
binary distribution, here is what I do.

-Stop MySQL
-Downoad the tarball in /usr/local/.
-Check the md5
-untar the tarball
-copy the content of the data directory of old version into new 
version's data directory.
-fix up the permissions like described in the INSTALL-BINARY file included
-delete the /usr/local/mysql symlink and re-creating another one 
pointing to the new version.
-Start MySQL
-Test

	Here is the problem:  After this procedure, I connect with a mysql 
client, use db, and then when I run a command like a select or update, 
the server crashes, giving me those errors on the client:

ERROR 2013: Lost connection to MySQL server during query

Or:

ERROR 2006: MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: db

When I go to the error log, here is what I got:

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=16384
read_buffer_size=258048
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections 
= 31615 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8908e40
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=0xbfe7eca8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x808af93
0x82d6de8
0x80c00bf
0x80bdeee
0x80ba6e9
0x80bcd51
0x80b9de6
0x809a1dd
0x809e6e9
0x8098def
0x8098778
0x8097eb7
0x82d459c
0x82fdf1a
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/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 0x890f370 = SELECT * FROM `ville`
thd->thread_id=1
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.

======================================

When resolving the stack trace, I get this:

/usr/local/mysql/bin/resolve_stack_dump -s ./symbols -n ./stack
0x808af93 handle_segfault + 423
0x82d6de8 pthread_sighandler + 184
0x80c00bf get_best_combination__FP4JOIN + 147
0x80bdeee 
make_join_statistics__FP4JOINP13st_table_listP4ItemP16st_dynamic_array + 
4206
0x80ba6e9 optimize__4JOIN + 457
0x80bcd51 
mysql_select__FP3THDPPP4ItemP13st_table_listUiRt4List1Z4ItemP4ItemUiP8st_orderT7T5T7UlP13select_resultP18st_select_lex_unitP13s

+ 745
0x80b9de6 handle_select__FP3THDP6st_lexP13select_result + 150
0x809a1dd mysql_execute_command__FP3THD + 1241
0x809e6e9 mysql_parse__FP3THDPcUi + 169
0x8098def dispatch_command__F19enum_server_commandP3THDPcUi + 1643
0x8098778 do_command__FP3THD + 188
0x8097eb7 handle_one_connection + 615
0x82d459c pthread_start_thread + 220
0x82fdf1a thread_start + 4

Any help would be appreciated.

Please let me know if you need more info.

Thanks,

Ugo

Thread
4.1.7 serious problemsUgo Bellavance4 Nov
  • Re: 4.1.7 serious problemsAnders Green4 Nov
    • Re: 4.1.7 serious problemsUgo Bellavance5 Nov
  • Re: 4.1.7 serious problemsGleb Paharenko5 Nov
    • Re: 4.1.7 serious problemsUgo Bellavance5 Nov
Re: 4.1.7 serious problemsHeikki Tuuri6 Nov
  • RE: 4.1.7 serious problemsDonny Simonton6 Nov
  • Re: 4.1.7 serious problemsUgo Bellavance8 Nov
    • Re: 4.1.7 serious problemsSasha Pachev11 Nov
      • Re: 4.1.7 serious problemsUgo Bellavance11 Nov
        • Re: 4.1.7 serious problemsSasha Pachev12 Nov
          • Re: 4.1.7 serious problemsUgo Bellavance12 Nov
            • Re: 4.1.7 serious problemsSasha Pachev13 Nov
              • Re: 4.1.7 serious problemsUgo Bellavance13 Nov
                • Re: 4.1.7 serious problemsSasha Pachev18 Nov
                  • Re: 4.1.7 serious problemsUgo Bellavance18 Nov
                    • Re: 4.1.7 serious problemsSasha Pachev18 Nov
                      • Re: 4.1.7 serious problemsUgo Bellavance19 Nov