[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: Crash probably in libthr
From:       Konstantin Belousov <kostikbel () gmail ! com>
Date:       2014-06-28 11:04:34
Message-ID: 20140628110434.GB93733 () kib ! kiev ! ua
[Download RAW message or body]


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.


[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]