Crash probably in libthr

[arrowdodger]

On Sat, Jun 28, 2014 at 2:21 AM, Grzegorz Blach <grzegorz at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at 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.