From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 1 19:37:03 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 CAD56EC2 for ; Tue, 1 Jul 2014 19:37:03 +0000 (UTC) Received: from mo6.mail-out.ovh.net (7.mo6.mail-out.ovh.net [46.105.59.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6338026DB for ; Tue, 1 Jul 2014 19:37:03 +0000 (UTC) Received: from mail423.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo6.mail-out.ovh.net (Postfix) with SMTP id F2871FFA3DB for ; Tue, 1 Jul 2014 16:49:43 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 1 Jul 2014 16:50:48 +0200 Received: from user-109-243-138-16.play-internet.pl (HELO starpad.nine) (grzegorz@blach.pl@109.243.138.16) by ns0.ovh.net with SMTP; 1 Jul 2014 16:50:45 +0200 Message-ID: <53B2CA82.6030504@blach.pl> Date: Tue, 01 Jul 2014 16:49:38 +0200 From: Grzegorz Blach User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Crash probably in libthr References: <53A95016.3090901@blach.pl> <20140624205420.GZ93733@kib.kiev.ua> <53ADEE4C.2080804@blach.pl> <20140628110434.GB93733@kib.kiev.ua> In-Reply-To: <20140628110434.GB93733@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 14611084567781727936 X-Ovh-Remote: 109.243.138.16 (user-109-243-138-16.play-internet.pl) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejfedrudduucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejfedrudduucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Mailman-Approved-At: Tue, 01 Jul 2014 19:45:31 +0000 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: Tue, 01 Jul 2014 19:37:04 -0000 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 think >>>> 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-FILE-dimurhxlz4tvytoxnfup/valgrind2.log >>>> Backtrace from gdb: >>>> https://phab.enlightenment.org/file/data/zvbelqzjt4h3ppates6a/PHID-FILE-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. >> 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. > >> 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 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. 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-n2iww677ot6b4rlbko2e/gdb3.log Also I found crashes in two another places: https://phab.enlightenment.org/file/data/nlqs7yxy4oqztqq7nc6f/PHID-FILE-7igyjfusokhy4z3zceu2/gdb4.log https://phab.enlightenment.org/file/data/wxf3rfsggxnuaieyuacb/PHID-FILE-g3r7dw5tdn3hdnqcnltx/gdb5.log But crash reported in gdb3.log file is the most common.