Bug 1321552

Created attachment 1140823 [details]
File: backtrace

Created attachment 1140824 [details]
File: cgroup

Created attachment 1140825 [details]
File: core_backtrace

Created attachment 1140826 [details]
File: dso_list

Created attachment 1140827 [details]
File: environ

Created attachment 1140828 [details]
File: exploitable

Created attachment 1140829 [details]
File: limits

Created attachment 1140830 [details]
File: maps

Created attachment 1140831 [details]
File: mountinfo

Created attachment 1140832 [details]
File: namespaces

Created attachment 1140833 [details]
File: open_fds

Created attachment 1140834 [details]
File: proc_pid_status

Created attachment 1140835 [details]
File: var_log_messages

It seems like bug in glibc package, so I will change name of component.

What's the exact version of the glibc package?  Thanks,

I forgot to mention: Please also show us your /etc/resolc.conf file (particular the nameserver lines).

glibc-2.22-11.fc23.x86_64 as for now, but who knows what was here when I reported this (I didn't do any general update since according to dnf history, only some installs or specific packages updates etc.).

# Generated by NetworkManager
search redhat.com
nameserver 10.38.5.26
nameserver 10.35.255.14
nameserver 8.8.8.8
# POZNÁMKA: překladač adres z libc nemůže podporovat více než 3 jmenné servery.
# Jmenné servery uvedené v následujícím seznamu nelze rozpoznat.
nameserver 8.8.4.4


Note that in the time of this crash, this file could be fairly different.
Also the note there says that libc cannot recognize more than 3 nameservers and the following nameservers could not be recognized.

Miro, do you still have a core file of this crash?  Thanks.

I believe everything I have is attached by ABRT, isn't it? There is core_backtrace.

Or do you mean something different? Where would I look for such file?

(In reply to Miro Hrončok from comment #19)
> I believe everything I have is attached by ABRT, isn't it? There is
> core_backtrace.
> 
> Or do you mean something different? Where would I look for such file?

ABRT should have saved a core file into a subdirectory for /var/spool/abrt.  This file may contain private data.  You can put it onto an internal shell server or send it to me by email if you don't want to attach it to this bug report.

Thanks, sending it via e-mail

Miro provided a coredump, but it is in a different place:

$8 = {callback_data = 0x55a8b0003a40,
  callback_funcs = 0x7f27c3d46280 <g_source_callback_funcs>,
  source_funcs = 0x7f27c3d46340 <g_timeout_funcs>, ref_count = 2,
  context = 0x55a8afe3a520, priority = 0, flags = 65, source_id = 6690, poll_fds = 0x2,
  prev = 0x56dca1da, next = 0x0,
  name = 0xffffffff <error: Cannot access memory at address 0xffffffff>,
  priv = 0x7f27b002a540}

At least the poll_fds field is corrupted, it is supposed to be a pointer.

I don't think this is a glibc bug, it doesn't match anything we have seen.

More data from the coredump:

(gdb) bt
#0  0x00007f27c3a544d4 in block_source (source=source@entry=0x55a8aff858f0) at gmain.c:3047
#1  0x00007f27c3a57f68 in g_main_context_dispatch (context=0x55a8afe3a520) at gmain.c:3136
#2  0x00007f27c3a57f68 in g_main_context_dispatch (context=context@entry=0x55a8afe3a520) at gmain.c:3769
#3  0x00007f27c3a581d0 in g_main_context_iterate (context=0x55a8afe3a520, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#4  0x00007f27c3a584f2 in g_main_loop_run (loop=0x55a8afe26f80) at gmain.c:4034
#5  0x000055a8afb974cd in main (argc=1, argv=0x7ffe165b5308) at utils/cups-browsed.c:6097
(gdb) l
3042	  if (source->context)
3043	    {
3044	      tmp_list = source->poll_fds;
3045	      while (tmp_list)
3046	        {
3047	          g_main_context_remove_poll_unlocked (source->context, tmp_list->data);
3048	          tmp_list = tmp_list->next;
3049	        }
3050	
3051	      for (tmp_list = source->priv->fds; tmp_list; tmp_list = tmp_list->next)
(gdb) print source
$1 = (GSource *) 0x55a8aff858f0
(gdb) disassemble 
Dump of assembler code for function block_source:
   0x00007f27c3a54480 <+0>:	mov    0x2c(%rdi),%eax
   0x00007f27c3a54483 <+3>:	test   $0x40,%al
   0x00007f27c3a54485 <+5>:	je     0x7f27c3a544a8 <block_source+40>
   0x00007f27c3a54487 <+7>:	lea    0x77547(%rip),%rdx        # 0x7f27c3acb9d5
   0x00007f27c3a5448e <+14>:	lea    0x7843b(%rip),%rsi        # 0x7f27c3acc8d0 <__func__.12808>
   0x00007f27c3a54495 <+21>:	lea    0x704d2(%rip),%rdi        # 0x7f27c3ac496e
   0x00007f27c3a5449c <+28>:	jmpq   0x7f27c3a5e9b0 <g_return_if_fail_warning>
   0x00007f27c3a544a1 <+33>:	nopl   0x0(%rax)
   0x00007f27c3a544a8 <+40>:	push   %rbp
   0x00007f27c3a544a9 <+41>:	push   %rbx
   0x00007f27c3a544aa <+42>:	or     $0x40,%eax
   0x00007f27c3a544ad <+45>:	mov    %rdi,%rbp
   0x00007f27c3a544b0 <+48>:	sub    $0x8,%rsp
   0x00007f27c3a544b4 <+52>:	mov    %eax,0x2c(%rdi)
   0x00007f27c3a544b7 <+55>:	mov    0x20(%rdi),%rdi
   0x00007f27c3a544bb <+59>:	test   %rdi,%rdi
   0x00007f27c3a544be <+62>:	je     0x7f27c3a5450d <block_source+141>
   0x00007f27c3a544c0 <+64>:	mov    0x38(%rbp),%rbx
   0x00007f27c3a544c4 <+68>:	test   %rbx,%rbx
   0x00007f27c3a544c7 <+71>:	jne    0x7f27c3a544d4 <block_source+84>
   0x00007f27c3a544c9 <+73>:	jmp    0x7f27c3a544e5 <block_source+101>
   0x00007f27c3a544cb <+75>:	nopl   0x0(%rax,%rax,1)
   0x00007f27c3a544d0 <+80>:	mov    0x20(%rbp),%rdi
=> 0x00007f27c3a544d4 <+84>:	mov    (%rbx),%rsi
   0x00007f27c3a544d7 <+87>:	callq  0x7f27c3a54400 <g_main_context_remove_poll_unlocked>
   0x00007f27c3a544dc <+92>:	mov    0x8(%rbx),%rbx
   0x00007f27c3a544e0 <+96>:	test   %rbx,%rbx
   0x00007f27c3a544e3 <+99>:	jne    0x7f27c3a544d0 <block_source+80>
   0x00007f27c3a544e5 <+101>:	mov    0x58(%rbp),%rax
   0x00007f27c3a544e9 <+105>:	mov    0x18(%rax),%rbx
   0x00007f27c3a544ed <+109>:	test   %rbx,%rbx
   0x00007f27c3a544f0 <+112>:	je     0x7f27c3a54516 <block_source+150>
   0x00007f27c3a544f2 <+114>:	nopw   0x0(%rax,%rax,1)
   0x00007f27c3a544f8 <+120>:	mov    (%rbx),%rsi
   0x00007f27c3a544fb <+123>:	mov    0x20(%rbp),%rdi
   0x00007f27c3a544ff <+127>:	callq  0x7f27c3a54400 <g_main_context_remove_poll_unlocked>
   0x00007f27c3a54504 <+132>:	mov    0x8(%rbx),%rbx
   0x00007f27c3a54508 <+136>:	test   %rbx,%rbx
   0x00007f27c3a5450b <+139>:	jne    0x7f27c3a544f8 <block_source+120>
   0x00007f27c3a5450d <+141>:	mov    0x58(%rbp),%rax
   0x00007f27c3a54511 <+145>:	test   %rax,%rax
   0x00007f27c3a54514 <+148>:	je     0x7f27c3a54531 <block_source+177>
   0x00007f27c3a54516 <+150>:	mov    (%rax),%rbx
   0x00007f27c3a54519 <+153>:	test   %rbx,%rbx
   0x00007f27c3a5451c <+156>:	je     0x7f27c3a54531 <block_source+177>
   0x00007f27c3a5451e <+158>:	xchg   %ax,%ax
   0x00007f27c3a54520 <+160>:	mov    (%rbx),%rdi
   0x00007f27c3a54523 <+163>:	callq  0x7f27c3a54480 <block_source>
   0x00007f27c3a54528 <+168>:	mov    0x8(%rbx),%rbx
   0x00007f27c3a5452c <+172>:	test   %rbx,%rbx
   0x00007f27c3a5452f <+175>:	jne    0x7f27c3a54520 <block_source+160>
   0x00007f27c3a54531 <+177>:	add    $0x8,%rsp
   0x00007f27c3a54535 <+181>:	pop    %rbx
   0x00007f27c3a54536 <+182>:	pop    %rbp
   0x00007f27c3a54537 <+183>:	retq   
End of assembler dump.

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.