MySQL Bugs: #7950: Mysqld Porcess is down.

Bug #7950	Mysqld Porcess is down.
Submitted:	17 Jan 2005 4:06	Modified:	20 Jan 2005 13:46
Reporter:	ChongHwan Lee	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:	3.23.53	OS:	Linux (Linux 2.4.20-28.7bigmem)
Assigned to:		CPU Architecture:	Any

Description:
I used to mysql 3.23.53 to replication..

sometimes Replication DB server is down under this message..

maybe it seems to be thread processing in bad memory handle stack.

so.. I just want to know What's the exactly reason..

OS version is Read Hat - 7.3

Kernel version is 2.4.20-28.7bigmem.

[ROOT@LOCAL HOST]$ uname -a
Linux tanta-dbbackup 2.4.20-28.7bigmem #1 SMP Thu Dec 18 11:04:21 EST 2003 i686 unknown

This message is mysqld.stack dump trace..

[root@LOCAL HOST]# resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack
0x8084e2f handle_segfault__Fi + 431
0x827a496 pthread_sighandler + 162
0x82ad21b memcpy + 39
0x82648be memdup_root + 190
0x80eb34d mysqld_list_processes__FP3THDPCcb + 2045
0x808d78b mysql_execute_command__Fv + 7259
0x808f063 mysql_parse__FP3THDPcUi + 195
0x808b06f do_command__FP3THD + 1407
0x808a4d9 handle_one_connection__FPv + 601

========================mysql.err===========================
Warning: Ignoring user change to 'mysql' because the user was set to 'mysql' earlier on the command line
/usr/local/mysql/libexec/mysqld: ready for connections
050115  9:35:40  Slave: connected to master 'repli@xxx.xxx.xx.xxx:3306',  replication started in log 'LOG.270' at position 323
[root@local host]# tail -n 50 mysqlerr.log
0x808d78b
0x808f063
0x808b06f
0x808a4d9
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 0x84bb018 = show processlist
thd->thread_id=845

Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 845 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

How to repeat:
one day 3 times down.

what is the problem?

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://www.mysql.com/doc/en/Making_trace_files.html

Once you have generated a backtrace, please submit it to this bug
report and change the status back to 'Open'. Thank you for helping
us make our products better.

sorry didn't notice that stack trace is already resolved..

but doesn't know how to verify this bug. If you have any ideas how to repeat it please let us know. We need repeatable test case.