Opened 8 years ago

Closed 6 years ago

#1850 closed defect (wontfix)

core dump at isc::server_common::portconfig::installListenAddresses when Error while reading data from cc session

Reported by: jreed Owned by:
Priority: medium Milestone: Remaining BIND10 tickets
Component: Unclassified Version: bind10-old
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Medium
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 4 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

on macmini:

core from b10-auth

#0  0x930a3176 in __kill ()
#1  0x930a3168 in kill$UNIX2003 ()
#2  0x9313589d in raise ()
#3  0x9314b9bc in abort ()
#4  0x00653347 in isc::server_common::portconfig::installListenAddresses ()
#5  0x0000d29d in AuthSrv::setListenAddresses ()
#6  0x0001bccc in (anonymous namespace)::ListenAddressConfig::build ()
#7  0x0001b0e3 in configureAuthServer ()
#8  0x0000dce6 in AuthSrv::updateConfig ()
#9  0x00024f89 in (anonymous namespace)::my_config_handler ()
#10 0x00396760 in isc::config::ModuleCCSession::handleConfigUpdate ()
#11 0x003985c1 in isc::config::ModuleCCSession::ModuleCCSession ()
#12 0x00025846 in main ()

This was configured with four b10-auth components.

I think the corresponding logging is:

2012-03-27 12:32:10.427 FATAL [b10-auth.server_common] SRVCOMM_EXCEPTION_ALLOC exception when allocating a socket: Error while reading data from cc session: End of file.

There were several "Error while reading data from cc session" and CC_READ_ERROR and a traceback in b10-cfgmgr at same time:

Traceback (most recent call last):
  File "/Local/Users/jreed/dnsbench/work/master/20120327130322/install/libexec/bind10-devel/b10-cfgmgr", line 112, in <module>
    sys.exit(main())
  File "/Local/Users/jreed/dnsbench/work/master/20120327130322/install/libexec/bind10-devel/b10-cfgmgr", line 100, in main
    cm.run()
  File "/Local/Users/jreed/dnsbench/work/master/20120327130322/install/lib/python3.1/site-packages/isc/config/cfgmgr.py", line 558, in run
    answer = self.handle_msg(msg);
  File "/Local/Users/jreed/dnsbench/work/master/20120327130322/install/lib/python3.1/site-packages/isc/config/cfgmgr.py", line 535, in handle_msg
    answer = self.__handle_module_spec(isc.config.ModuleSpec(arg))
  File "/Local/Users/jreed/dnsbench/work/master/20120327130322/install/lib/python3.1/site-packages/isc/config/cfgmgr.py", line 485, in __handle_module_spec
    spec.get_full_spec())
  File "/Local/Users/jreed/dnsbench/work/master/20120327130322/install/lib/python3.1/site-packages/isc/config/cfgmgr.py", line 511, in _send_module_spec_to_cmdctl
rver_common] SRVCOMM_EXCEPTION_ALLOC exception when allocating a socket: Error while reading data from cc session: End of file.
    self.cc.group_sendmsg(spec_update, "Cmdctl")
  File "/Local/Users/jreed/dnsbench/work/master/20120327130322/install/lib/python3.1/site-packages/isc/cc/session.py", line 268, in group_sendmsg
2012-03-27 12:32:10.427 ERROR [b10-boss.boss] BIND10_COMPONENT_FAILED component b10-auth-4 (pid 34532) failed: process exited normally with exit status 256
    }, isc.cc.message.to_wire(msg))
  File "/Local/Users/jreed/dnsbench/work/master/20120327130322/install/lib/python3.1/site-packages/isc/cc/session.py", line 101, in sendmsg

(note that some regular logging is mixed in above)

Subtickets

Change History (7)

comment:1 follow-up: Changed 8 years ago by vorner

This is the desired behaviour I believe. This is how the thing reacts to not being able to close previous sockets/give them up to boss. If we ignored the error, the system would end up in an inconsistent state, so we terminate here. The problem with msgq is a separate issue. OK to close as invalid?

comment:2 in reply to: ↑ 1 ; follow-up: Changed 8 years ago by jreed

Replying to vorner:

This is the desired behaviour I believe. This is how the thing reacts to not being able to close previous sockets/give them up to boss. If we ignored the error, the system would end up in an inconsistent state, so we terminate here. The problem with msgq is a separate issue. OK to close as invalid?

I'd prefer not to close it yet. The system had over 800 core dumps from BIND 10 which used up all disk space. In that case it is not desired :)

comment:3 in reply to: ↑ 2 ; follow-up: Changed 8 years ago by jinmei

Replying to jreed:

This is the desired behaviour I believe. This is how the thing reacts to not being able to close previous sockets/give them up to boss. If we ignored the error, the system would end up in an inconsistent state, so we terminate here. The problem with msgq is a separate issue. OK to close as invalid?

I'd prefer not to close it yet. The system had over 800 core dumps from BIND 10 which used up all disk space. In that case it is not desired :)

Terminating the process is probably okay. Using abort() is too harsh
though. I'd suggesting throwing something like auth::FatalError?,
which is not expected to be caught in the middle of the process and
should be only used for emergency (but as graceful as possible)
termination.

comment:4 in reply to: ↑ 3 Changed 8 years ago by vorner

Replying to jinmei:

Terminating the process is probably okay. Using abort() is too harsh
though. I'd suggesting throwing something like auth::FatalError?,
which is not expected to be caught in the middle of the process and
should be only used for emergency (but as graceful as possible)
termination.

Throwing something that is not caught would cause the abort in the end anyway (at least with gcc, an uncaught exception is handled above main() by calling abort()). And we could be able to catch it by accident, with some catch (std::exception) or catch (...). What is the benefit of using an exception instead of abort?

comment:5 Changed 8 years ago by shane

  • Defect Severity changed from N/A to Medium
  • Milestone changed from New Tasks to Next-Sprint-Proposed

comment:6 Changed 6 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:7 Changed 6 years ago by tomek

  • Resolution set to wontfix
  • Status changed from new to closed
  • Version set to old-bind10

This issue is related to bind10 code that is no longer part of Kea.

If you are interested in BIND10/Bundy framework or its DNS components,
please check http://bundy-dns.de.

Closing ticket.

Note: See TracTickets for help on using tickets.