MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Gleb Paharenko Date:November 4 2004 7:58pm
Subject:Re: 4.1.7 serious problems
View as plain text  
Hi.
There were several posts in list like yours.
Do you use InnoDB tables? Try to increase values
of key_buffer_size, read_buffer_size and so on.


Ugo Bellavance <ugob@stripped> wrote:
> 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
> 
> 


-- 
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.NET http://www.ensita.net/
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /    Gleb Paharenko
 / /|_/ / // /\ \/ /_/ / /__   Gleb.Paharenko@stripped
/_/  /_/\_, /___/\___\_\___/   MySQL AB / Ensita.NET
       <___/   www.mysql.com



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