From owner-freebsd-hackers Wed Jan 24 16:30:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from temphost.dragondata.com (temphost.dragondata.com [63.167.131.128]) by hub.freebsd.org (Postfix) with ESMTP id EBE3337B404 for ; Wed, 24 Jan 2001 16:29:54 -0800 (PST) Received: (from toasty@localhost) by temphost.dragondata.com (8.9.3/8.9.3) id SAA23574; Wed, 24 Jan 2001 18:29:58 -0600 (CST) (envelope-from toasty) From: Kevin Day Message-Id: <200101250029.SAA23574@temphost.dragondata.com> Subject: Pthreads with sprintf/dtoa To: hackers@freebsd.org Date: Wed, 24 Jan 2001 18:29:58 -0600 (CST) Cc: kevin@stileproject.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After upgrading to FreeBSD 4.2(from 4.1) and MySQL 3.23.32 (from 3.22.32), I kept seeing mysqld crashes after a few minutes of heavy load. I traced it down to one rather situation. Every time it crashed, I was getting a segfault inside __dtoa (which was called by sprintf). If I looked at other threads, I'd always see another thread inside __dtoa at that point too. I went back to 3.22.32, and it still happened, so my current guess is something between 4.1-RELEASE and 4.2-RELEASE. I'm really highly ignorant of pthreads, so I have no idea if they(myslqd) is doing something wrong thread-wise, or something got broken so that it's no longer thread safe inside sprintf or dtoa. Can someone cluefull point me in the right direction? -- Kevin Forwarded message: > From toasty Wed Jan 24 17:55:36 2001 > From: Kevin Day > Message-Id: <200101242355.RAA21536@temphost.dragondata.com> > Subject: Re: Field_float::val_str crash in 3.23.32 > To: mysql@lists.mysql.com > Date: Wed, 24 Jan 2001 17:55:31 -0600 (CST) > Cc: toasty@dragondata.com, stile@stileproject.com > In-Reply-To: <20010124153714.A14455@yahoo-inc.com> from "Jeremy D. Zawodny" at Jan 24, 2001 03:37:14 PM > X-Mailer: ELM [version 2.5 PL3] > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > > > On Wed, Jan 24, 2001 at 03:15:48PM -0600, Jeremy D. Zawodny wrote: > > > > Does this only occur when more than one client is accessing the table > > in question? If so, it's a thread-related problem that has been with > > us since FreeBSD 3.x. :-( > > > > It looks like what I've seen before. > > > > I have a re-produceable case that I sent to one of the MySQL > > developers and he was able to see the problem. Tracing it down, > > however, requires someone who knows a lot about FreeBSD threading. > > > > I've found some FreeBSD gurus here who might be able to help. I just > > need a MySQL developer to point them at... > > > > Well, I did find something interesting... Right now, I crashed in thread #1: > > * 1 process 48183, thread 1 0x282c835c in bcopy () from /usr/lib/libc_r.so.4 > > > with the trace: > > #0 0x282c835c in bcopy () from /usr/lib/libc_r.so.4 > #1 0x282da0a8 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 > #2 0x282c9cca in __dtoa () from /usr/lib/libc_r.so.4 > #3 0x282c7b3b in vfprintf () from /usr/lib/libc_r.so.4 > #4 0x282c5c56 in vfprintf () from /usr/lib/libc_r.so.4 > #5 0x282b74cd in sprintf () from /usr/lib/libc_r.so.4 > #6 0x806a779 in Field_float::val_str (this=0x8f6bcb8, val_buffer=0xbf68b30c, val_ptr=0xbf68b30c) at field.cc:1849 > #7 0x80671dd in Field::send (this=0x8f6bcb8, packet=0x8a2b420) at field.cc:257 > #8 0x814ae5f in Item_field::send (this=0x8adab60, str_arg=0x8a2b420) at item.h:119 > #9 0x8072612 in select_send::send_data (this=0x8ada6a8, items=@0x8a2b24c) at sql_class.cc:236 > #10 0x80a9207 in end_send (join=0xbf68b75c, join_tab=0x8c88868, end_of_records=false) at sql_select.cc:4521 > #11 0x80a7bc9 in sub_select (join=0xbf68b75c, join_tab=0x8c88750, end_of_records=false) at sql_select.cc:4033 > #12 0x80a7666 in do_select (join=0xbf68b75c, fields=0x8a2b24c, table=0x0, procedure=0x0) at sql_select.cc:3925 > #13 0x809c82f in mysql_select (thd=0x8a2b000, tables=0x8ada0d8, fields=@0x8a2b24c, conds=0x8ada5c8, ftfuncs=@0x8a2b280, > order=0x8ada688, group=0x0, having=0x0, proc_param=0x0, select_options=8950784, result=0x8ada6a8) at sql_select.cc:755 > #14 0x8082331 in mysql_execute_command () at sql_parse.cc:957 > #15 0x808561f in mysql_parse (thd=0x8a2b000, > inBuf=0x8ada010 "SELECT * FROM cp WHERE C11=1 && C12>=1.0 && C13>=1.0 && PL1 > 0 ORDER BY C4 DESC", length=80) > at sql_parse.cc:2085 > #16 0x8081634 in do_command (thd=0x8a2b000) at sql_parse.cc:668 > #17 0x8080938 in handle_one_connection (arg=0x8a2b000) at sql_parse.cc:403 > #18 0x2825b9a7 in _thread_start () from /usr/lib/libc_r.so.4 > #19 0xbf933ffc in ?? () > #20 0x28292f99 in select () from /usr/lib/libc_r.so.4 > #21 0x807d01d in handle_connections_sockets (arg=0x0) at mysqld.cc:2099 > #22 0x807c440 in main (argc=9, argv=0x81d7228) at mysqld.cc:1830 > #23 0x804b2fd in _start () > Using the running image of child process 48183, thread 1. > Program stopped at 0x282c835c. > It stopped with signal SIGSEGV, Segmentation fault. > > > > Notice frame #2. > > > If I look at other threads, I see this: > > 100 process 48183, thread 100 0x282ca140 in __dtoa () from /usr/lib/libc_r.so.4 > > #0 0x282ca140 in __dtoa () from /usr/lib/libc_r.so.4 > #1 0x282c7b3b in vfprintf () from /usr/lib/libc_r.so.4 > #2 0x282c5c56 in vfprintf () from /usr/lib/libc_r.so.4 > #3 0x282b74cd in sprintf () from /usr/lib/libc_r.so.4 > #4 0x806a779 in Field_float::val_str (this=0x90d3448, val_buffer=0xbf9cc30c, val_ptr=0xbf9cc30c) at field.cc:1849 > #5 0x80671dd in Field::send (this=0x90d3448, packet=0x8ba0420) at field.cc:257 > #6 0x814ae5f in Item_field::send (this=0x92d4ac0, str_arg=0x8ba0420) at item.h:119 > #7 0x8072612 in select_send::send_data (this=0x92d46a8, items=@0x8ba024c) at sql_class.cc:236 > #8 0x80a9207 in end_send (join=0xbf9cc75c, join_tab=0x8bc5868, end_of_records=false) at sql_select.cc:4521 > #9 0x80a7bc9 in sub_select (join=0xbf9cc75c, join_tab=0x8bc5750, end_of_records=false) at sql_select.cc:4033 > #10 0x80a7666 in do_select (join=0xbf9cc75c, fields=0x8ba024c, table=0x0, procedure=0x0) at sql_select.cc:3925 > #11 0x809c82f in mysql_select (thd=0x8ba0000, tables=0x92d40d8, fields=@0x8ba024c, conds=0x92d45c8, ftfuncs=@0x8ba0280, > order=0x92d4688, group=0x0, having=0x0, proc_param=0x0, select_options=8950784, result=0x92d46a8) at sql_select.cc:755 > #12 0x8082331 in mysql_execute_command () at sql_parse.cc:957 > #13 0x808561f in mysql_parse (thd=0x8ba0000, > inBuf=0x92d4010 "SELECT * FROM cp WHERE C11=1 && C12>=1.0 && C13>=1.0 && PL1 > 0 ORDER BY C4 DESC", length=80) > at sql_parse.cc:2085 > #14 0x8081634 in do_command (thd=0x8ba0000) at sql_parse.cc:668 > #15 0x8080938 in handle_one_connection (arg=0x8ba0000) at sql_parse.cc:403 > #16 0x2825b9a7 in _thread_start () from /usr/lib/libc_r.so.4 > #17 0xbf7f0ffc in ?? () > #18 0x28292f99 in select () from /usr/lib/libc_r.so.4 > #19 0x807d01d in handle_connections_sockets (arg=0x0) at mysqld.cc:2099 > #20 0x807c440 in main (argc=9, argv=0x81d7228) at mysqld.cc:1830 > #21 0x804b2fd in _start () > > > Is something with sprintf/dtoa not being done in a reentrant/thread-safe > manner? If I look at what's happening with sprintf there, everything mysql > is doing seems correct. > > > > -- Kevin > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message