Date: Sat, 16 Aug 2014 22:24:47 +0400 From: arrowdodger <6yearold@gmail.com> To: Grzegorz Blach <grzegorz@blach.pl> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Crash probably in libthr Message-ID: <CALH631mfAPRbGzfA5XK=MfzFC9y51scwhkEQGYPJ7tD93O1_SQ@mail.gmail.com> In-Reply-To: <53ADEE4C.2080804@blach.pl> References: <53A95016.3090901@blach.pl> <20140624205420.GZ93733@kib.kiev.ua> <53ADEE4C.2080804@blach.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 28, 2014 at 2:21 AM, Grzegorz Blach <grzegorz@blach.pl> 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? > > 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." > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > So, what's the status of this? I could lend a hand with debugging/testing this, although my gdb skills are far from expert.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALH631mfAPRbGzfA5XK=MfzFC9y51scwhkEQGYPJ7tD93O1_SQ>