Bug 1370024

Created attachment 1193867 [details]
File: backtrace

Created attachment 1193868 [details]
File: cgroup

Created attachment 1193869 [details]
File: core_backtrace

Created attachment 1193870 [details]
File: dso_list

Created attachment 1193871 [details]
File: environ

Created attachment 1193872 [details]
File: exploitable

Created attachment 1193873 [details]
File: limits

Created attachment 1193874 [details]
File: maps

Created attachment 1193875 [details]
File: mountinfo

Created attachment 1193876 [details]
File: namespaces

Created attachment 1193877 [details]
File: open_fds

Created attachment 1193878 [details]
File: proc_pid_status

Created attachment 1193879 [details]
File: var_log_messages

tdesc_find_feature() has range 0x...f00 - 0x...f73 but the ABRT backtrace contains:
#0  0x804abacc in tdesc_find_feature ...
I do not understand the ABRT output.

This seems to be sort of random thing. I'm not sure if it's reproduceable. But where indicates the function's actual range?

My comment was more for ABRT people although they do not read it here anyway.
The function range is from:

# debuginfo-install gdb
$ gdb gdb
(gdb) disas tdesc_find_feature
Dump of assembler code for function tdesc_find_feature:
   0x0000000000438f00 <+0>:	mov    0x20(%rdi),%rax
[...]
   0x0000000000438f72 <+114>:	retq   
End of assembler dump.
(gdb) 

You can ignore address offsets modulo 0x1000 as all executables incl. GDB are PIE (Position Independent Executable) now in Fedora.

well, on this machine, I got:


Reading symbols from gdb...Reading symbols from /usr/lib/debug/usr/bin/gdb.debug...done.
done.
  File "/usr/lib/debug/usr/bin/gdb-gdb.py", line 91
    print "Warning: Cannot find enum type_flag_value type."
                                                          ^
SyntaxError: Missing parentheses in call to 'print'
(gdb) disassemble tdesc_find_feature
Dump of assembler code for function tdesc_find_feature:
   0x00443a90 <+0>:	push   %ebp
   0x00443a91 <+1>:	push   %edi
   0x00443a92 <+2>:	push   %esi
   0x00443a93 <+3>:	push   %ebx
   0x00443a94 <+4>:	call   0xa5380 <__x86.get_pc_thunk.bx>
   0x00443a99 <+9>:	add    $0x4569e3,%ebx
   0x00443a9f <+15>:	lea    -0x2c(%esp),%esp
   0x00443aa3 <+19>:	mov    0x40(%esp),%eax
   0x00443aa7 <+23>:	mov    0x10(%eax),%esi
   0x00443aaa <+26>:	test   %esi,%esi
   0x00443aac <+28>:	je     0x443ae3 <tdesc_find_feature+83>
   0x00443aae <+30>:	mov    (%esi),%eax
   0x00443ab0 <+32>:	test   %eax,%eax
   0x00443ab2 <+34>:	mov    %eax,0x1c(%esp)
   0x00443ab6 <+38>:	je     0x443ae3 <tdesc_find_feature+83>
   0x00443ab8 <+40>:	xor    %ebp,%ebp
   0x00443aba <+42>:	lea    0x0(%esi),%esi
   0x00443ac0 <+48>:	mov    0x8(%esi,%ebp,4),%edi
   0x00443ac4 <+52>:	mov    0x44(%esp),%eax
   0x00443ac8 <+56>:	mov    %eax,0x4(%esp)
   0x00443acc <+60>:	mov    (%edi),%eax
   0x00443ace <+62>:	mov    %eax,(%esp)
   0x00443ad1 <+65>:	call   0xa0530 <strcmp@plt>
   0x00443ad6 <+70>:	test   %eax,%eax
   0x00443ad8 <+72>:	je     0x443af0 <tdesc_find_feature+96>
   0x00443ada <+74>:	lea    0x1(%ebp),%ebp
   0x00443add <+77>:	cmp    0x1c(%esp),%ebp
   0x00443ae1 <+81>:	jne    0x443ac0 <tdesc_find_feature+48>
   0x00443ae3 <+83>:	lea    0x2c(%esp),%esp
   0x00443ae7 <+87>:	xor    %eax,%eax
   0x00443ae9 <+89>:	pop    %ebx
   0x00443aea <+90>:	pop    %esi
   0x00443aeb <+91>:	pop    %edi
   0x00443aec <+92>:	pop    %ebp
   0x00443aed <+93>:	ret    
   0x00443aee <+94>:	xchg   %ax,%ax
   0x00443af0 <+96>:	lea    0x2c(%esp),%esp
   0x00443af4 <+100>:	mov    %edi,%eax
   0x00443af6 <+102>:	pop    %ebx
   0x00443af7 <+103>:	pop    %esi
---Type <return> to continue, or q <return> to quit---
   0x00443af8 <+104>:	pop    %edi
   0x00443af9 <+105>:	pop    %ebp
   0x00443afa <+106>:	ret    
End of assembler dump.
(gdb) 

The funciton's addresses here seem reasonable to me. I know position independent code, but not familiar with PIE. Does it mean the whole executable's addresses can be mapped differently in different environment?

(In reply to 汪明衡 from comment #17)
> well, on this machine, I got:

Ah, I have only now realized you run i686, not x86_64


> I know position
> independent code, but not familiar with PIE. Does it mean the whole
> executable's addresses can be mapped differently in different environment?

Even differently on each run on the same machine:
  https://en.wikipedia.org/wiki/Position-independent_code#PIE

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.