> tscn> We've recently been seeing this on other FreeBSD 3.2
> systems, also.
> tscn> After tracking it down for a while, it is definitely a problem
> tscn> in the FreeBSD 3.2 libc_r.so, and namely appears to be
> tscn> caused by some changes in thread priority handling in that
> tscn> library between 3.1 and 3.2.
>
> So this is FreeBSD bug? Have you notified them about it?
Yes, it appears to be a FreeBSD bug. We just discovered it last
Friday, so I have not yet notified them of it. It is rather difficult
to reproduce except under quite heavy load.
> tscn> Most, but not quite all, of the queries causing our
> sig 11s were
> tscn> also using unix_timestamp calls, and failing in a thread_mutex
> tscn> call (after localtime_r) in libc_r.
>
> What would be you recommendations for now? Shell I downgrade to
> FreeBSD 3.1 or build static mysql on FreeBSD 3.1 and run it
> on 3.2? Any
> advise would be very appreciated!
We worked around the problem by using a static mysqld built on 3.1.
That worked quite well.
-Troy Cobb
Circle Net, Inc.
http://www.circle.net
> Sergey Gershtein
>
>
> tscn> -Troy Cobb
> tscn> Circle Net, Inc.
> tscn> http://www.circle.net
>
> >> -----Original Message-----
> >> From: Sergey Gershtein [mailto:sg@stripped]
> >> Sent: Monday, June 28, 1999 2:58 AM
> >> To: mysql@stripped
> >> Subject: mysqld (3.22.23b) dumps core (segmentation
> violation) under
> >> high load after upgrading to FreeBSD 3.2
> >>
> >>
> >> >Description:
> >>
> >> I've been using mysql for a long time and it used to work very
> >> stable until lately. Recently after uprgading from
> FreeBSD 3.1 to
> >> FreeBSD 3.2 mysqld started dumping core regularly with
> signal 11
> >> (segmentation violation) at moments of high load. There seems
> >> to be no particular query that is garanteed to kills
> >> mysqld, although
> >> it often (but not always) dies during the query
> specified below.
> >>
> >> The specifics of usage is that mysql gets a lot of
> 'replace delayed'
> >> queries (up to 7-10 queries a second) on one table
> while different
> >> selects are done on other tables. Till the very death mysql
> >> performs very well, giving fast answers and taking
> only 1-3% of cpu
> >> load. The death itself is instant and unpredictable. There is
> >> nothing left in any log files about it.
> >>
> >> All connetions to mysql are done from perl scripts via
> >> Msql-Mysql-modules-1.2014 using dynamic link library
> >> libmysqlclient.so.6.0
> >>
> >> I tried to compile mysql with --with-debug, but I was
> unable to get
> >> it working. The daemon would start and accept connections, but
> >> would not reply to any queries, including even 'mysqladmin
> >> status' or
> >> 'mysqladmin version'.
> >>
> >> >How-To-Repeat:
> >>
> >> Here is the query that most often kills mysql. This query
> >> is executed
> >> repeatedly in a program and the table 'urlcheck' is
> modified between
> >> the queries. Usually the query succiedes several times
> (3 to 10) and
> >> then mysql server dies during this query.
> >>
> >> select
> >> id,
> >> min(unix_timestamp(now())-
> >>
> unix_timestamp(ifnull(checktime,'1980-01-01 00:00:00')))
> >> as dtime
> >> from
> >> resource left join urlcheck on id=res_id
> >> where
> >> include = '1'
> >> group by id
> >> order by dtime desc
> >> limit 1
> >>
> >> Here's the structures of the tables mentioned:
> >>
> >> create table urlcheck (
> >> res_id integer not null,
> >> checktime timestamp not null,
> >> time_win integer,
> >> time_koi integer,
> >> time_eng integer,
> >> err_win integer,
> >> err_koi integer,
> >> err_eng integer,
> >> index index_res_id( res_id ),
> >> index index_checktime( checktime )
> >> );
> >>
> >> create table resource (
> >> id integer not null auto_increment primary key,
> >> login char[20] not null,
> >> url_win varchar(200),
> >> url_koi varchar(200),
> >> url_eng varchar(200),
> >> title varchar(80) not null,
> >> keywords text,
> >> description text,
> >> cmt_user text,
> >> email varchar(80),
> >> person varchar(80),
> >> phone varchar(80),
> >> host varchar(80),
> >> street text,
> >> city varchar(80),
> >> region enum( 'svrd','perm','chel','oren',
> >> 'kurg','tumn','other','-') not null
> >> default '-',
> >> country varchar(80),
> >> regdate date not null,
> >> apprdate date,
> >> apprby varchar(30),
> >> include enum("0","1","-") not null,
> >> cmt_admin text,
> >> index idx_include( include ),
> >> unique idx_login( login ),
> >> index idx_region( region )
> >> );
> >>
> >>
> >> >Fix:
> >>
> >> Unknown
> >>
> >> >Submitter-Id: <submitter ID>
> >> >Originator: Sergey Gershtein <sg@stripped>
> >> >Organization: Ural Relcom Ltd, Ekaterinburg, Russia
> >> >MySQL support: none
> >> >Synopsis: mysqld dump core (segmentation violation)
> >> under high load after upgrade to FreeBSD 3.2
> >> >Severity: serious
> >> >Priority: high
> >> >Category: mysql
> >> >Class: sw-bug
> >> >Release: mysql-3.22.23b (Source distribution)
> >>
> >> >Environment:
> >> System: FreeBSD dream.mplik.ru 3.2-STABLE FreeBSD
> >> 3.2-STABLE #1: Thu Jun 24 14:55:03 YEKST 1999
> >> sg@stripped:/usr/src/sys/compile/DREAM i386
> >> Some paths: /usr/bin/perl /usr/bin/make
> >> /usr/local/bin/gmake /usr/bin/gcc /usr/bin/cc
> >> GCC: gcc version 2.7.2.1
> >> Compilation info: CC='gcc' CFLAGS='-O6 -m486
> >> -D_THREAD_SAFE' CXX='gcc' CXXFLAGS='-O6 -m486
> >> -D_THREAD_SAFE' LDFLAGS=''
> >> Perl: This is perl, version 5.005_02 built for i386-freebsd
> >> Configure command:
> >> ./configure --prefix=/usr/servers/mysql-3.22.23b \
> >> --localstatedir=/usr/servers/mysql-3.22.23b/data \
> >>
> --with-unix-socket-path=/usr/servers/mysql/mysql.sock \
> >> --without-bench \
> >> --without-perl \
> >> --with-charset=koi8_ru \
> >> --with-make=gmake \
> >> --without-debug \
> >> --without-readline \
> >> --with-mit-threads=no
> >>
> >> ------------------------------------------------------------
> >> ---------
> >> Please check
> >> > "http://www.mysql.com/Manual_chapter/manual_toc.ht> ml"
> >>
> >> before
> >> posting. To request this thread, e-mail
> >> mysql-thread6033@stripped
> >>
> >> To unsubscribe, send a message to the address shown in the
> >> List-Unsubscribe header of this message. If you cannot see it,
> >> e-mail mysql-unsubscribe@stripped instead.
> >>
>
>
