>>>>> "Daniel" == Daniel Simms <dsimms@stripped> writes:
Daniel> Hi all,
Daniel> I've been pursuing a infrequent stack corruption problem for a couple
Daniel> of months now and am wondering if there are any other victims of this
Daniel> type of problem. (I haven't seen any on the list nor in the change
Daniel> log, but perhaps I didn't look hard enough... if so, scold me.)
Daniel> I don't really have enough information to submit a proper bug report
Daniel> (or fix it myself, as I would gladly do). What I do know is this:
Daniel> # [root@lc /root]# uname -a
Daniel> # BSD/OS lc.alink.net 3.1 BSDI BSD/OS 3.1 Kernel #13: Fri Dec 18 00:02:12 PST
> 1998 root@stripped:/usr/src/sys/compile/ALINK i386
Daniel> # [root@lc /root]# /usr/local/mysql/libexec/mysqld -v
Daniel> # /usr/local/mysql/libexec/mysqld Ver 3.22.15-gamma for pc-bsdi3.1 on i386
Daniel> # [root@lc /root]# gcc -v
Daniel> # gcc version 220.127.116.11
Daniel> I also know that in my_thread_id (in mysys/my_thr_init.c),
Daniel> my_thread_var (which is really the pointer returned by
Daniel> pthread_getspecific) is NULL. At the same time, the stack is so badly
Daniel> mangled that signal handlers can't even be called. The stack pointer
Daniel> isn't obviously the result of any overflow I can see, either based on
Daniel> the immediate prior query, or the value of the stack pointer
Daniel> (0xd6f6d), or plain code analysis. I also get cores now but they're
Daniel> not easily helpful since the backtrace is only ever one frame deep.
Daniel> I've tried to do more debugging of the possible callers of
Daniel> my_thread_id, but there are way too many to do anything useful with.
Daniel> The only redeeming qualities to this situation are that it happens
Daniel> fairly infrequently (varying between once in two days, and once in 2
Daniel> weeks), and that no corruption results (at least as far as
>> find /usr/local/mysql/var/ -type f -name '*.ISM' | xargs
> /usr/local/mysql/bin/isamchk -s'
Daniel> Any one interested in or suffering from this? Let me know what I can
For the moment I think the best action is to upgrade to MySQL 3.22.21,
egcs 1.1.2. You should also run mysqld with --log to be able to check
if it is some specific query that kills MySQL.
Please check the MySQL manual, section 'What to do if mysqld keeps
crashing' for a lot of tips of how to locate the problem!