Date: Tue, 01 Jul 2014 16:49:38 +0200 From: Grzegorz Blach <grzegorz@blach.pl> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Crash probably in libthr Message-ID: <53B2CA82.6030504@blach.pl> In-Reply-To: <20140628110434.GB93733@kib.kiev.ua> References: <53A95016.3090901@blach.pl> <20140624205420.GZ93733@kib.kiev.ua> <53ADEE4C.2080804@blach.pl> <20140628110434.GB93733@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <error reading >> variable: Cannot access memory at address 0x0> or <optimized out>). 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53B2CA82.6030504>