Re: Crash probably in libthr

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.

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"