Crash probably in libthr

[Grzegorz Blach]

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."