max-3.23.53a crash?

[Lars Andersson]

Hi,

Today I had a crash on my production server running Max-3.23.53a

It has the following specifications
================
MySQL-Max3.23.53a
RedHat 7.3
Kernel 2.4.18-SMP
Glibc-2.2.5-42
2GB of memory


When I resolv my stack_dump I get the following. Can anyone make something useful out of this? I was not running with any other logging, I've turned it on now if this is going to be happening a lot (remembering the glibc problems...)
==========
resolve_stack_dump -s /usr/lib/mysql/mysqld.sym -n mysqld.stack
0x806eeb4 init_signals__Fv + 16
0x82d9b38 _end + 421148
0x80ada70 test_quick_select__10SQL_SELECTUlUlUlb + 828
0x80af33c key_or__FP7SEL_ARGT0 + 316
0x80aef61 key_and__FP7SEL_ARGT0Ui + 573
0x80ae1fd get_mm_tree__FP13st_qsel_paramP4Item + 1121
0x80adead get_mm_tree__FP13st_qsel_paramP4Item + 273
0x8090ebf make_join_readinfo__FP4JOINUi + 735
0x808ce3a mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UiP13select_result + 3258
0x8075d90 mysql_execute_command__Fv + 1628
0x8079ecc reload_acl_and_cache__FP3THDUiP13st_table_list + 280
0x8074f34 do_command__FP3THD + 2276
0x80742e7 handle_bootstrap__FPv + 303

The complete log looks like this.
=============
/usr/sbin/mysqld-max: 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 agaist 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=131072
sort_buffer=2097144
max_used_connections=60
max_connections=400
threads_connected=3
It is possible that mysqld could use up to
key_buffer_size + (record_buffer + sort_buffer)*max_connections = 1263608 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:
Stack range sanity check OK, backtrace follows:
0x806eeb4
0x82d9b38
0x80ada70
0x80af33c
0x80aef61
0x80ae1fd
0x80adead
0x8090ebf
0x808ce3a
0x8075d90
0x8079ecc
0x8074f34
0x80742e7
Stack trace seems successful - bottom reached
Please read http://www.mysql.com/doc/U/s/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 0x8c509020 is invalid pointer
thd->thread_id=3282450

Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 3282450 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
021113 18:28:15 mysqld restarted
021113 18:28:15 Can't start server: Bind on TCP/IP port: Address already in use
021113 18:28:15 Do you already have another mysqld server running on port: 3306 ?
021113 18:28:15 Aborting


/Lars


---------------------------------------------------------------------
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