Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jan 2001 18:29:58 -0600 (CST)
From:      Kevin Day <toasty@temphost.dragondata.com>
To:        hackers@freebsd.org
Cc:        kevin@stileproject.com
Subject:   Pthreads with sprintf/dtoa
Message-ID:  <200101250029.SAA23574@temphost.dragondata.com>

next in thread | raw e-mail | index | archive | help


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 <toasty>
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101250029.SAA23574>