From: Michael Widenius Date: April 6 1999 10:28am Subject: stack smash on bsdi 3.1? List-Archive: http://lists.mysql.com/mysql/1450 Message-Id: <14089.57701.752356.739267@analytik.analytikerna.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> "Daniel" == Daniel Simms 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 2.7.2.1 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. Hi! 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! Regards, Monty