Bug 62845
| Summary: | update of mysql40-server causes mysqld to segfault on remote connection | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Erik Greenwald <erik> |
| Component: | Individual Port(s) | Assignee: | Alex Dupre <ale> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | erik |
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Erik Greenwald
2004-02-14 18:10:06 UTC
Responsible Changed From-To: freebsd-ports-bugs->ale Over to maintainer. I cannot reproduce the problem: armada# mysql -h armada -u pippo Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 6 to server version: 4.0.18 Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> \s -------------- mysql Ver 12.22 Distrib 4.0.18, for portbld-freebsd5.2 (i386) Connection id: 6 Current database: Current user: pippo@armada.alexdupre.com SSL: Not in use Current pager: more Using outfile: '' Server version: 4.0.18 Protocol version: 10 Connection: armada via TCP/IP Client characterset: latin1 Server characterset: latin1 TCP port: 3306 Uptime: 3 min 14 sec Threads: 1 Questions: 19 Slow queries: 0 Opens: 12 Flush tables: 1 Open tables: 1 Queries per second avg: 0.098 -------------- armada# ldd /usr/local/libexec/mysqld /usr/local/libexec/mysqld: libwrap.so.3 => /usr/lib/libwrap.so.3 (0x2837d000) libpthread.so.1 => /usr/lib/libpthread.so.1 (0x28385000) libz.so.2 => /lib/libz.so.2 (0x283aa000) libcrypt.so.2 => /lib/libcrypt.so.2 (0x283b8000) libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x283d1000) libm.so.2 => /lib/libm.so.2 (0x2848d000) libc.so.5 => /lib/libc.so.5 (0x284a6000) Did you build mysql with any knobs? -- Alex Dupre On Sun, Feb 15, 2004 at 12:58:01AM +0100, Alex Dupre wrote: > I cannot reproduce the problem: hrm :/ > armada# ldd /usr/local/libexec/mysqld > /usr/local/libexec/mysqld: > libwrap.so.3 => /usr/lib/libwrap.so.3 (0x2837d000) > libpthread.so.1 => /usr/lib/libpthread.so.1 (0x28385000) > libz.so.2 => /lib/libz.so.2 (0x283aa000) > libcrypt.so.2 => /lib/libcrypt.so.2 (0x283b8000) > libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x283d1000) > libm.so.2 => /lib/libm.so.2 (0x2848d000) > libc.so.5 => /lib/libc.so.5 (0x284a6000) hrm, I have the same linkage :/ erik@fenris ~$ ldd /usr/local/libexec/mysqld /usr/local/libexec/mysqld: libwrap.so.3 => /usr/lib/libwrap.so.3 (0x28320000) libpthread.so.1 => /usr/lib/libpthread.so.1 (0x28328000) libz.so.2 => /lib/libz.so.2 (0x2834b000) libcrypt.so.2 => /lib/libcrypt.so.2 (0x28358000) libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x28370000) libm.so.2 => /lib/libm.so.2 (0x28422000) libc.so.5 => /lib/libc.so.5 (0x2843a000) > Did you build mysql with any knobs? nope, not to my knowledge... whatever portupgrade does on a new install... I'll try to get the binary running in gdb... I should probably do a system upgrade, as well... I'm on -current as of feb 07 ... there may've been a small bug or something that tickles mysqld funny > > -- > Alex Dupre -- -Erik <erik@smluc.org> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. Erik Greenwald wrote: >>Did you build mysql with any knobs? > > nope, not to my knowledge... whatever portupgrade does on a new install... Ok, same setup here. > I'll try to get the binary running in gdb... I should probably do a system > upgrade, as well... I'm on -current as of feb 07 ... there may've been a small > bug or something that tickles mysqld funny Today's current here. -- Alex Dupre On Sun, Feb 15, 2004 at 01:36:58AM +0100, Alex Dupre wrote: > Erik Greenwald wrote: <snip> > Ok, same setup here. > > >I'll try to get the binary running in gdb... I should probably do a system > >upgrade, as well... I'm on -current as of feb 07 ... there may've been a > >small > >bug or something that tickles mysqld funny > > Today's current here. I did a new 'world' and kernel last night and I still have this crash. :/ FreeBSD fenris 5.2-CURRENT FreeBSD 5.2-CURRENT #1: Sat Feb 14 21:56:11 EST 2004 root@fenris:/usr/obj/usr/src/sys/FENRIS i386 this is the bin that seems to be crashing, as called... /usr/local/libexec/mysqld --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/db/mysql/fenris.pid Here is what happens when I run it as the mysql user directly (same happens if ran as root) ==================================================================== $ /usr/local/libexec/mysqld --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/db/mysql/fenris.pid 040215 9:27:08 InnoDB: Started /usr/local/libexec/mysqld: ready for connections. Version: '4.0.18' socket: '/tmp/mysql.sock' port: 3306 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 against 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=8388600 read_buffer_size=131072 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. $ id uid=88(mysql) gid=88(mysql) groups=88(mysql) $ ==================================================================== when I try to trap it in gdb, it doesn't throw the signal, but it goes into 'stopped' mode and stops responding (so the client hangs waiting for server chatter instead of returning the error) $ gdb /usr/local/libexec/mysqld GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"...(no debugging symbols found)... (gdb) run --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/db/mysql/fenris.pid Starting program: /usr/local/libexec/mysqld --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/db/mysql/fenris.pid (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... 040215 9:30:30 InnoDB: Started /usr/local/libexec/mysqld: ready for connections. Version: '4.0.18' socket: '/tmp/mysql.sock' port: 3306 and when I hop in another shell... erik@fenris ~$ ps ax | grep mysqld 84724 p3 I 0:00.23 gdb /usr/local/libexec/mysqld 85378 p3 TX+ 0:00.56 /usr/local/libexec/mysqld --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/db/mysql/fenris.pid the gdb wrapped mysql doesn't respond to ^C or ^Z, or any signals as delivered by kill. but gdb itself respond to stop and kill (not int or quit). I've tried connecting to that server with the 4.0.17 client on macos (from fink) and get the exact same results. I tried a couple different ip's on that machine, and it only seems to talk fine on localhost/loopback, not the ether driven "real" ip's. truss doesn't seem to issue any interesting information at all, even with the -fadeD options. I'm wondering if there're threads going on that truss can't follow? (if so, that might be what's confusing gdb, too?) > > -- > Alex Dupre -- -Erik <erik@smluc.org> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. Erik Greenwald wrote:
> I did a new 'world' and kernel last night and I still have this crash. :/
CPUTYPE, CFLAGS and CXXFLAGS?
--
Alex Dupre
On Mon, Feb 16, 2004 at 12:46:24AM +0100, Alex Dupre wrote: <snip> > CPUTYPE, CFLAGS and CXXFLAGS? all are default, so I guess CPUTYPE is i686, CFLAGS is -O -pipe and cxx is the same... the proc is an athlon tbird if that makes a difference... If necessary, I can dump a log of the build, as well as the truss log on a web spot. I can't post a core as the mysqld program intercepts the segfault... I'm currently building with the 'skip dns check' option and the makefile modified to build debugging info in... will continue to modify options/environment until it seems to magically work, and keep you apprised. -- -Erik <erik@smluc.org> [http://math.smsu.edu/~erik] Any news? Do you still have this problem or is it specific to only a particular system? -- Alex Dupre On Sat, Mar 13, 2004 at 10:55:58AM +0100, Alex Dupre wrote: > Any news? Do you still have this problem or is it specific to only a > particular system? <snip> I couldn't reproduce the symptom on intel based machines, and lack another non-intel to do that testing... however; misc/63213 indicates that other people are seeing it... (should the pr's be merged or something?) I'm just now getting back to a stage where I can commit some time in to researching this... hopefully I'll be able to provide some new information in the near future... -- -Erik <erik@smluc.org> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. Erik Greenwald wrote: > I couldn't reproduce the symptom on intel based machines, and lack > another non-intel to do that testing... however; misc/63213 indicates > that other people are seeing it... (should the pr's be merged or > something?) Yes, done...a question: do you have this problem also if you use the package instead of compiling the port yourself? (if you like I can send you a package of the latest version, tested to work here). -- Alex Dupre On Sat, Mar 13, 2004 at 11:31:55PM +0100, Alex Dupre wrote: <snip> > Yes, done...a question: do you have this problem also if you use the > package instead of compiling the port yourself? (if you like I can send > you a package of the latest version, tested to work here). > > -- > Alex Dupre I just tried deleting the mysql40-server package and installing using: erik@fenris ~$ portupgrade -NPPs databases/mysql40-server the same behavior is showing... full output is as follows... erik@fenris ~$ portupgrade -PPs databases/mysql40-server ---> [Executing a command as root: sudo /usr/local/sbin/pkgdb -u] ---> Updating the pkgdb [Updating the pkgdb <format:bdb1_btree> in /var/db/pkg ... - 213 packages found (-1 +0) (...) done] ** No such package 'databases/mysql40-server' is installed. erik@fenris ~$ portupgrade -NPPs databases/mysql40-server ---> Checking the availability of the latest package of 'databases/mysql40-server' ---> Fetching the package(s) for 'mysql-server-4.0.18_1' (databases/mysql40-server) ---> Fetching mysql-server-4.0.18_1 /usr/tmp/mysql-server-4.0.18_1.tbz 100% of 3810 kB 349 kBps 00m00s ---> Downloaded as mysql-server-4.0.18_1.tbz ---> Identifying the package /usr/tmp/mysql-server-4.0.18_1.tbz ---> Saved as /usr/ports/packages/All/mysql-server-4.0.18_1.tbz ---> Found a package of 'databases/mysql40-server': /usr/ports/packages/All/mysql-server-4.0.18_1.tbz ---> Installing 'mysql-server-4.0.18_1' from a package ---> Installing the new version via the package ---> [Executing a command as root: sudo /usr/bin/script -qa /tmp/portupgrade22495.0 /usr/sbin/pkg_add -f mysql-server-4.0.18_1] mysql:*:88: You already have a group "mysql", so I will use it. mysql:*:88:88::0:0:MySQL Daemon:/var/db/mysql:/bin/sh You already have a user "mysql", so I will use it. Changed home directory of "mysql" to "/var/db/mysql" ---> [Executing a command as root: sudo /usr/local/sbin/pkgdb -aFQ] [Updating the pkgdb <format:bdb1_btree> in /var/db/pkg ... - 214 packages found (-0 +1) . done] erik@fenris ~$ if you'd like me to try another build, I can... (on a perhaps related note; I'm seeing sig11's from GL using apps caused by pthread_key_create()... Program received signal SIGSEGV, Segmentation fault. 0x280dc775 in pthread_key_create () from /usr/lib/libpthread.so.1 (gdb) bt #0 0x280dc775 in pthread_key_create () from /usr/lib/libpthread.so.1 #1 0x281435cc in __nvsym17681 () from /usr/X11R6/lib/libGL.so.1 #2 0x280508f1 in _rtld () from /libexec/ld-elf.so.1 (gdb) I'm wondering if perhaps this is the root cause of the mysql-server failure on my machine... x11-toolkits/qt33 triggers this behavior consistantly on build (uic is the segging process)... I've started writing up some code to try to figure out where exactly it happens... perhaps this is only exhibited with c++? once I have the crash isolated, I should be able to get to the root of that, and cross my fingers and hope a fix for that fixes mysqld?) thanks... -- -Erik <erik@smluc.org> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. Hi, everybody. I have the same bug with mysql-4.0... mysqld was compiled from ports (without extra options and ), and it works OK via local unix-socket only, but fails when client tries to connect via TCP. ===From .err file=================================== /usr/local/libexec/mysqld: ready for connections. Version: '4.0.18' socket: '/tmp/mysql.sock' port: 3306 <<< TCP connect here >>> 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 against 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=8388600 read_buffer_size=131072 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Number of processes running now: 0 040322 14:20:45 mysqld restarted 040322 14:20:54 InnoDB: Started /usr/local/libexec/mysqld: ready for connections. Version: '4.0.18' socket: '/tmp/mysql.sock' port: 3306 ===From client console (TCP connection)=============== mars# mysql -h velvet -u root -p Enter password: ERROR 2013: Lost connection to MySQL server during query velvet# mysql -h velvet -u root -p Enter password: ERROR 2013: Lost connection to MySQL server during query ===From client console (unix socket connection)========== velvet# mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 to server version: 4.0.18 Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> =============================================== -- Yours sincerely, Yan Batuto Web Hosting, Karavannaya str., 1. Saint-Petersburg. Russia http://www.valuehost.ru http://hostforum.ru Call: +7 (812) 320-8785, +7 (095) 737-0973 Fax: +7 (812) 325-8897, +7 (095) 737-0973 This is definitely a problem that appears when building the port on some specific systems (package created by me works on all platforms). So I need to know from you: - FreeBSD version - if FreeBSD has been installed by binaries or by make world (flags?) - GCC version - compiler flags (/etc/make.conf) - port settings (i.e. BUILD_STATIC, PTHREAD_LIBS, etc.) - CPU (AMD, Intel, etc.) - other things you may think useful for finding the issue -- Alex Dupre It seems I am hitting the same bug on AMD64 (Opteron, 242). The system was installed from 5.2.1-RELEASE CD, then rebuild from sources for RELENG_5_2 as of Monday March 22nd, 2004 (not sure about time). The mysql was built from sources on the machine already RELEN_5_2/2004-03-22. Could you please cross-compile the package for AMD64, package built in your environment will work also on AMD64 ? Thank you in advance, Milon -- mmp@actinet.cz This has been tracked to a GCC issue, so this pr can be closed...
--
-Erik <erik@smluc.org> [http://math.smsu.edu/~erik]
State Changed From-To: open->closed Requested by submitter. State Changed From-To: closed->analyzed The GCC issue is not reported to be fixed; this does not belong in "closed". State Changed From-To: analyzed->closed This has been fixed in 4.0.20. I am encountering the same problem on mysql-4.0.20. binary install of freebsd 5.2.1-RELEASE; amd64. mysql installed from ports without options. Installing mysql-4.0.20 from sources results in the same problem, as does installing mysql-server-3.23.58_2 from ports. gcc (GCC) 3.3.3 [FreeBSD] 20031106 make.conf is empty __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ It's a bug when libwrap is involved. Removed that option and all's well. This is not fixed in 4.0.20, and it's not an AMD-specific problem. I believe Cadams analysis is correct. 5.2-CURRENT as of about 20 minutes ago CPU: Intel(R) XEON(TM) CPU 2.40GHz (2395.93-MHz 686-class CPU) (two of them, SMP kernel) real memory = 2146959360 (2047 MB) 511 mit-network-monitor:/x/db> gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.3 [FreeBSD] 20031106 Mysql crashes when installed from packages or from ports, with or without BUILD_OPTIMZIED. I'm using native threads. As Cadams found, removing --with-librap from the Make configure arguments solved the crashing problems. I couldn't reproduce it anymore, with mysql 4.0.20. # make -V CPUTYPE # make install # mysql -h 192.168.0.177 Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 to server version: 4.0.20 Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> \s -------------- mysql Ver 12.22 Distrib 4.0.20, for portbld-freebsd5.2 (i386) Connection id: 1 Current database: Current user: root@armada.alexdupre.com SSL: Not in use Current pager: more Using outfile: '' Server version: 4.0.20 Protocol version: 10 Connection: 192.168.0.177 via TCP/IP Client characterset: latin1 Server characterset: latin1 TCP port: 3306 Uptime: 14 sec Threads: 1 Questions: 2 Slow queries: 0 Opens: 6 Flush tables: 1 Open tables: 0 Queries per second avg: 0.143 -------------- -- Alex Dupre Hello, this problem affects mysql323 too. Can someone commit the (apparent) fix also to the 323-port ? I think it was forgotten. cheers, Rainer |
