Date: Sat, 28 Jun 2014 14:04:34 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Grzegorz Blach <grzegorz@blach.pl> Cc: freebsd-hackers@freebsd.org Subject: Re: Crash probably in libthr Message-ID: <20140628110434.GB93733@kib.kiev.ua> 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
--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 <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. --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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140628110434.GB93733>