Hello.
You have a rather old version and it is built manually. I suggest you to upgrade to the latest release (4.1.11 or if it is impossible, then to 4.0.24). And check if problem is solved after that. kevin korngut <[EMAIL PROTECTED]> wrote: > [-- text/plain, encoding 7bit, charset: ISO-8859-1, 74 lines --] > > I'm attempting to configure mysql with InnoDB tables and I'm running > into problems. And am using the following version of mysqld-max, Ver > 4.0.18-Max for suse-linux on i686 (Source distribution) > > First I uncommented the following lines in /etc/my.cnf: > # Uncomment the following if you are using InnoDB tables > innodb_data_home_dir = /var/lib/mysql/ > innodb_data_file_path = ibdata1:10M:autoextend > innodb_log_group_home_dir = /var/lib/mysql/ > innodb_log_arch_dir = /var/lib/mysql/ > # You can set .._buffer_pool_size up to 50 - 80 % > # of RAM but beware of setting memory usage too high > innodb_buffer_pool_size = 16M > innodb_additional_mem_pool_size = 2M > # Set .._log_file_size to 25 % of buffer pool size > innodb_log_file_size = 5M > innodb_log_buffer_size = 8M > innodb_flush_log_at_trx_commit = 1 > innodb_lock_wait_timeout = 50 > > Then I attempted to start mysqld-max as the user mysql (mysqld-max -u > mysql) and got 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=16777216 > read_buffer_size=131072 > max_used_connections=0 > max_connections=100 > threads_connected=0 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections > = 80383 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0x8434638 > 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... > Bogus stack limit or frame pointer, fp=0xbffbcea4, > stack_bottom=0x7ca35f80, thread_stack=196608, aborting backtrace. > Trying to get some variables. > Some pointers may be invalid and cause the dump to abort... > thd->query at 0x7bcf0ff0 is invalid pointer > thd->thread_id=0 > 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. > > I then tried mysqld-max -u root which created the InnoDB file; however, > when I then attempted to start mysql I got the above error (again, > running it as the user mysql and not as root) > > Anyone seen this or happen to know what's going on? > > > > -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Gleb Paharenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
