From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 28 11:07: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 92985DEF for ; Sat, 28 Jun 2014 11:07: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 325E52CFC for ; Sat, 28 Jun 2014 11:07:10 +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 s5SB4Y5R009723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jun 2014 14:04:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s5SB4Y5R009723 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s5SB4YMP009722; Sat, 28 Jun 2014 14:04:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 28 Jun 2014 14:04:34 +0300 From: Konstantin Belousov To: Grzegorz Blach Subject: Re: Crash probably in libthr Message-ID: <20140628110434.GB93733@kib.kiev.ua> References: <53A95016.3090901@blach.pl> <20140624205420.GZ93733@kib.kiev.ua> <53ADEE4C.2080804@blach.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="klLku2wdS+WFztDq" Content-Disposition: inline In-Reply-To: <53ADEE4C.2080804@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: Sat, 28 Jun 2014 11:07:10 -0000 --klLku2wdS+WFztDq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 thi= nk > >> 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-FIL= E-dimurhxlz4tvytoxnfup/valgrind2.log > >> Backtrace from gdb: > >> https://phab.enlightenment.org/file/data/zvbelqzjt4h3ppates6a/PHID-FIL= E-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 while > > waiting for unblock. It appeared in the log because your process is > > multithreaded and that other thread slept waiting for an event. >=20 > Backtrace from valgrind is completely different than backtrace from gdb. > How do you think that backtrace is more appropriate? Because gdb backtrace looks sane, for me. >=20 > Also I posted your reply on https://phab.enlightenment.org/T1330 this is > an answer: >=20 > "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 point > 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. --klLku2wdS+WFztDq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTrqFBAAoJEJDCuSvBvK1BLc0P/R1t1sYqMGHZ1BTx6K3qHeiM ILXujIsjAOTKe8OPAFEST5AoSrzM/LjT8Kh9OVFZQIqF9Qy4MbUuHXMkRKaRIhKa seuJ8JZL3wW9PocR+qWwqqbUP8+hxJ4JEGcq0hyrUcdeZMlhTXoqrfMAydb6p4I7 BMW49uTKzHRVyVgwmKR7/ViPwanXgWQYb1iXY/repGC5gnaLzydTHp806NIPshoV RjCBVG/3bi3hKldSXEgPsNab0gJT/VSb7fla2FqfgSkn0p8cO1fJZ94vCS5Jme72 qCOZoePEt2pxlsUtjg2JumW2BaKKVJcZ7pmL1Lm4/p6VDs0/73sejDS8CFTFwW1/ YW+6tYo+Xo0f/sBWzcUVFEo7gchmR4DfIMqNqGt1ADtM33E9c/t3RrrW6zwjxGhw fIqAJbYnP2mfgZH2h/4YTACa6WEQrTtGSVli/xOdHVASQ74/FZjf98/7WU7Yeu99 /rC9i6P/Vii34HQ3nQ86QxmjePzNbvk5xr9sO4yevEsvFJGftnqX2KB2LwyJLBNQ 3/peJkPx/rSgfb1zBCEsF8q19mAjOaPP6KnnbdT28xohdwi8dH9ADDeMd9hAtndg sz0qx7K6IkDhYUEe6do9L5+0aI6pZjZlTa8bL/SPXmX11CVNewYIHxm1MVXbTBng XCIf075Yxt2awB8Vi1Dw =U3a5 -----END PGP SIGNATURE----- --klLku2wdS+WFztDq--