List:General Discussion« Previous MessageNext Message »
From:Michael Widenius Date:January 1 1970 12:00am
Subject:stack smash on bsdi 3.1?
View as plain text  
>>>>> "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 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

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> reports).

Daniel> Any one interested in or suffering from this?  Let me know what I can
Daniel> do.


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!

stack smash on bsdi 3.1?Daniel Simms6 Apr
  • stack smash on bsdi 3.1?Michael Widenius6 Apr