Date: Sat, 28 Jun 2014 00:21:00 +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: <53ADEE4C.2080804@blach.pl> In-Reply-To: <20140624205420.GZ93733@kib.kiev.ua> References: <53A95016.3090901@blach.pl> <20140624205420.GZ93733@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53ADEE4C.2080804>