From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 3 12:15:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22FD8EFF for ; Thu, 3 Jul 2014 12:15:10 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CA3D2FF9 for ; Thu, 3 Jul 2014 12:15:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s63CCWZo039675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2014 15:12:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s63CCWZo039675 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s63CCVVE039674; Thu, 3 Jul 2014 15:12:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Jul 2014 15:12:31 +0300 From: Konstantin Belousov To: Grzegorz Blach Subject: Re: Crash probably in libthr Message-ID: <20140703121231.GD93733@kib.kiev.ua> References: <53A95016.3090901@blach.pl> <20140624205420.GZ93733@kib.kiev.ua> <53ADEE4C.2080804@blach.pl> <20140628110434.GB93733@kib.kiev.ua> <53B2CA82.6030504@blach.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZVbJiTJMCrlhTKaH" Content-Disposition: inline In-Reply-To: <53B2CA82.6030504@blach.pl> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 12:15:10 -0000 --ZVbJiTJMCrlhTKaH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 01, 2014 at 04:49:38PM +0200, Grzegorz Blach wrote: >=20 > On 06/28/14 13:04, Konstantin Belousov wrote: > > On Sat, Jun 28, 2014 at 12:21:00AM +0200, Grzegorz Blach wrote: > >> On 06/24/14 22:54, Konstantin Belousov wrote: > >>> On Tue, Jun 24, 2014 at 12:16:54PM +0200, Grzegorz Blach wrote: > >>>> On https://phab.enlightenment.org/T1330 I reported a crash in > >>>> Enlightenment. After analyzing backtraces from valgrind and gdb we t= hink > >>>> this might be a bug in libthr. > >>> And how did you come to this conclusion ? > >>> > >>>> Backtrace from valgrind: > >>>> https://phab.enlightenment.org/file/data/wlcvu7kmb5blxmgtnk2p/PHID-F= ILE-dimurhxlz4tvytoxnfup/valgrind2.log > >>>> Backtrace from gdb: > >>>> https://phab.enlightenment.org/file/data/zvbelqzjt4h3ppates6a/PHID-F= ILE-dsnaw3golsozpzlb7uqe/gdb2.log > >>>> > >>>> Have any one known what > >>>> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 does? > >>> The gdb backtrace you posted reports that the SIGSEGV occured in the > >>> thread with lwp id 100363. According to the same log, innermost > >>> frame for the thread is in _op_blend_p_dp_mmx(), which is line 11 > >>> in the file src/lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c. > >>> > >>> umtx_op is the syscall which typically parks thread in the kernel whi= le > >>> waiting for unblock. It appeared in the log because your process is > >>> multithreaded and that other thread slept waiting for an event. > >> Backtrace from valgrind is completely different than backtrace from gd= b. > >> How do you think that backtrace is more appropriate? > > Because gdb backtrace looks sane, for me. > > > >> Also I posted your reply on https://phab.enlightenment.org/T1330 this = is > >> an answer: > >> > >> "As I stated before the gdb trace is at least messed up, especially as > >> the caller to the _op_blend_p_dp_mmx report a lot of impossible > >> information (all the parameter that int are marked >> variable: Cannot access memory at address 0x0> or ). I > >> fail to see how we could believe that nothing is messed up at that poi= nt > >> and that gdb report the problem at the right time." > > It is not messed up. Old gdb from the base system is unable to interpret > > some dwarf constructs which are needed to access the arguments values, > > which does not invalidate the backtrace itself. > > > > I prefer to avoid commenting on someone beliefs. >=20 > I'm using gdb771 from ports not gdb611 from base. I think -O1 in CFLAGS > was the reason. > Now I rebuild EFL with -O0, this is a new backtrace: > https://phab.enlightenment.org/file/data/hu4fuxi5mwalxxydudj4/PHID-FILE-n= 2iww677ot6b4rlbko2e/gdb3.log >=20 > Also I found crashes in two another places: > https://phab.enlightenment.org/file/data/nlqs7yxy4oqztqq7nc6f/PHID-FILE-7= igyjfusokhy4z3zceu2/gdb4.log > https://phab.enlightenment.org/file/data/wxf3rfsggxnuaieyuacb/PHID-FILE-g= 3r7dw5tdn3hdnqcnltx/gdb5.log >=20 > But crash reported in gdb3.log file is the most common. This backtrace clearly indicates that segmentation violation occured in modules/evas/engines/gl_common/evas_gl_context.c:1903. --ZVbJiTJMCrlhTKaH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTtUivAAoJEJDCuSvBvK1B0LwQAI8vm6zaeJHmSuBX87BUhx1z VmfYIw0h0IHWqgN7kdVTINGLuKkJTIDgB5SSasNjIImxXydScuzwOjetWaaIRwdB diiCkIesAhujMYq4/ku1tfbrPJdm+EGXJ7Sb19O7VR/8Yb/2NJgKURVJOMIwW7EW wBA1wGgwidFAX6PBxPPqiKjv00JYJiBEiNtP6gKpkjUhZQqGx4e/9fSuBY769eG4 H+FqgUPWCu/PU9haXQ72kmicAyMelPsPhdV3swxF/irLMBRi3aoGB2xMIgybbXLc gHNQDz0SOfgTLuOpL4vIuyFT2jjXglLzMHpWQDpAijpLHG0VPStc0BBnb13N/uOm pUAhqgNtKE8AgndKVvPoEfoDGOPMjLfy2BdYtsYXPINHqFkp7TEkExmbiUQUJ6h0 RqrSS2Nm5vE9iNTrYeqo9Lfay03Ef7y2AaZFFVVQ87g5Byxbx7T2Xqc2HNAR2sR+ gr/zWAbx6h5pjeGynNVG9X59bMHcJ0lD+cdw1xwKKZkBjcuESI5BKTL3Z5v4WF8R yvIM9CG9KNBncvjGaGgJnNbGBoifpIMXof8f1melcJ5guL42+07czw7A5ojm2vud CsxEPD9VZLGB2tKT3ec8pXd4KocmpLgMhOEZMM6i4C/fp95Kc9h9Oj9HkYImoXMp 4+ZufBHXaWtFCyGeoROT =DlMv -----END PGP SIGNATURE----- --ZVbJiTJMCrlhTKaH--