Crash probably in libthr

[Konstantin Belousov]

On Tue, Jul 01, 2014 at 04:49:38PM +0200, Grzegorz Blach wrote:
> 
> 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.

This backtrace clearly indicates that segmentation violation occured
in modules/evas/engines/gl_common/evas_gl_context.c:1903.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140703/268c2b93/attachment.sig>