This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 477989 - crash with dig +nsswitch ceplovi.cz ANY
crash with dig +nsswitch ceplovi.cz ANY
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-26 19:11 EST by Matěj Cepl
Modified: 2013-04-30 19:42 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:24:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
backtrace from the core file (2.05 KB, text/plain)
2008-12-30 17:16 EST, Matěj Cepl
no flags Details
coredump from bind-utils-9.6.0-2.P1.fc11.x86_64 (172.01 KB, application/x-bzip2)
2009-01-12 09:00 EST, Matěj Cepl
no flags Details
combined stderr/stdout from running dig @192.168.1.1 -d 99 ceplovi.cz ANY +nssearch (4.34 KB, text/plain)
2009-01-12 09:01 EST, Matěj Cepl
no flags Details

  None (edit)
Description Matěj Cepl 2008-12-26 19:11:17 EST
Description of problem:
Run the command mentioned in the Summary of this bug and got dig crashed with this backtrace:

Core was generated by `dig +nssearch ceplovi.cz ANY'.
Program terminated with signal 11, Segmentation fault.
[New process 17029]
[New process 17028]
[New process 17030]
[New process 17031]
#0  0x0805355b in send_done (_task=0xb7fa6008, event=0xb7fb53c8)
    at dighost.c:2171
2171	dighost.c: No such file or directory.
	in dighost.c
(gdb) thread apply all backtrace

Thread 4 (process 17031):
#0  0x00110416 in __kernel_vsyscall ()
#1  0x006d7836 in epoll_wait () from /lib/libc-2.9.so
#2  0x00829e59 in watcher (uap=0xb7fa9008) at socket.c:3245
#3  0x007a151f in start_thread (arg=0xb6ba1b90) at pthread_create.c:297
#4  0x006d704e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 3 (process 17030):
#0  0x00110416 in __kernel_vsyscall ()
#1  0x007a5432 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:179
#2  0x0082da54 in isc_condition_waituntil (c=0xb7fa7040, m=0xb7fa7010, 
    t=0xb7fa7038) at condition.c:59
#3  0x00818cbd in run (uap=0xb7fa7008) at timer.c:721
#4  0x007a151f in start_thread (arg=0xb75a2b90) at pthread_create.c:297
#5  0x006d704e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 2 (process 17028):
#0  0x00110416 in __kernel_vsyscall ()
#1  0x0061e8c7 in do_sigsuspend ()
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:63
#2  __sigsuspend (set=0xbff0cf80) at ../sysdeps/unix/sysv/linux/sigsuspend.c:78
#3  0x0081a7d2 in isc_app_run () at app.c:534
#4  0x080500b4 in main (argc=4, argv=0xbff0d174) at dig.c:1799

Thread 1 (process 17029):
#0  0x0805355b in send_done (_task=0xb7fa6008, event=0xb7fb53c8)
    at dighost.c:2171
#1  0x008163c7 in dispatch () at task.c:862
#2  run (uap=0xb7fa4008) at task.c:1005
#3  0x007a151f in start_thread (arg=0xb7fa3b90) at pthread_create.c:297
#4  0x006d704e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) 


Version-Release number of selected component (if applicable):
bind-utils-9.5.1-0.9.b3.fc10.i386

How reproducible:
1 of 2

Steps to Reproduce:
1.run the above mentioned command
2.
3.
  
Actual results:
collect the backtrace

Expected results:
getting the reply from DNS server

Additional info:
Comment 1 Gianluca Varisco 2008-12-30 03:12:43 EST
Matej,

I tested it on two boxes, one i686 and the other x86_64.

- bind-utils-9.5.1-0.9.b3.fc10.i386

;; Warning, extra type option
SOA dns1.master.cz. noc.master.cz. 2008121102 7200 7200 1209600 10800 from server dns2.master.cz in 13 ms.
SOA dns1.master.cz. noc.master.cz. 2008121102 7200 7200 1209600 10800 from server dns1.master.cz in 16 ms.

- bind-utils-9.5.1-0.9.b3.fc10.x86_64

;; Warning, extra type option
Segmentation fault

The strange thing is that it happened only the first time I launched it, as it has been executed without problem the second time:

$ dig +nssearch ceplovi.cz ANY
;; Warning, extra type option
SOA dns1.master.cz. noc.master.cz. 2008121102 7200 7200 1209600 10800 from server dns2.master.cz in 123 ms.
SOA dns1.master.cz. noc.master.cz. 2008121102 7200 7200 1209600 10800 from server dns1.master.cz in 71 ms.

Are you encountering this problem each time you launch 'dig +nssearch ceplovi.cz ANY'?
Comment 2 Matěj Cepl 2008-12-30 17:16:36 EST
Created attachment 327979 [details]
backtrace from the core file

Strange, I think that when I was reporting this it was 100% reproduction, but today it was like once per 10 attempts.
Comment 3 Matěj Cepl 2008-12-30 17:18:30 EST
I was changing the setup of my computer from using local bind to just relying on external nameservers, but I am not sure whether it was before or after filing this bug.
Comment 4 Matěj Cepl 2009-01-12 09:00:44 EST
Created attachment 328736 [details]
coredump from bind-utils-9.6.0-2.P1.fc11.x86_64

With bind-utils-9.5.1-0.9.b3.fc10.i386 I am not able to reproduce. No problem to reproduce with bind-utils-9.6.0-2.P1.fc11.x86_64.
Comment 5 Matěj Cepl 2009-01-12 09:01:42 EST
Created attachment 328737 [details]
combined stderr/stdout from running dig @192.168.1.1 -d 99 ceplovi.cz ANY +nssearch
Comment 6 Bug Zapper 2009-11-18 05:34:51 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 WONTFIX if it remains open with a Fedora 
'version' of '10'.

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 prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Bug Zapper 2009-12-18 02:24:51 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.

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

Note You need to log in before you can comment on or make changes to this bug.