View Issue Details

IDProjectCategoryView StatusLast Update
0001838GNUnetARM servicepublic2011-10-31 11:00
ReporterChristian Grothoff Assigned ToChristian Grothoff Due Date
PriorityhighSeveritycrashReproducibilityhave not tried
Status closedResolutionfixed 
Product VersionGit master 
Summary0001838: segfault on FreeBSD buildbot in NSE test in gnunet-arm
Description#0 0x000000080076e77c in GNUNET_NETWORK_get_fd (desc=0x0) at network.c:891
891 return desc->fd;
(gdb) ba
#0 0x000000080076e77c in GNUNET_NETWORK_get_fd (desc=0x0) at network.c:891
#1 0x000000080077a871 in GNUNET_SCHEDULER_add_write_net (delay=
      {rel_value = 1778}, wfd=0x0, task=0x800756360 <transmit_ready>,
    task_cls=0x80141b0c0) at scheduler.c:1482
#2 0x0000000800756ca9 in transmit_ready (cls=0x80141b0c0, tc=0x7fffffffe420)
    at connection.c:1608
#3 0x000000080077901b in run_ready (rs=0x801416080, ws=0x801416110)
    at scheduler.c:685
#4 0x00000008007797b2 in GNUNET_SCHEDULER_run (
    task=0x800773130 <program_main>, task_cls=0x7fffffffe6d0)
    at scheduler.c:867
#5 0x0000000800773a70 in GNUNET_PROGRAM_run (argc=7, argv=0x7fffffffe810,
    binaryName=0x402049 "gnunet-arm",
    binaryHelp=0x402010 "Control services and the Automated Restart Manager (ARM)", options=0x401de0, task=0x401120 <run>, task_cls=0x0) at program.c:252
#6 0x0000000000401913 in main (argc=7, argv=0x7fffffffe810)
    at gnunet-arm.c:415
TagsNo tags attached.

Activities

Christian Grothoff

2011-10-22 22:24

manager   ~0004723

connection.c details:

(gdb) print *sock
$6 = {cfg = 0x80140b080, ap_head = 0x0, ap_tail = 0x0, addr = 0x0,
  hostname = 0x80141a120 "localhost", sock = 0x0, receiver = 0,
  receiver_cls = 0x0, write_buffer = 0x80140e350 "", write_buffer_size = 4,
  write_buffer_off = 0, write_buffer_pos = 0, addrlen = 0, read_task = 0,
  write_task = 0, destroy_task = 0, dns_active = 0x0, nth = {
    notify_ready = 0x80074c340 <client_notify>,
---Type <return> to continue, or q <return> to quit---
    notify_ready_cls = 0x801415100, sh = 0x80141b0c0, transmit_timeout = {
      abs_value = 1319243148090}, timeout_task = 0, notify_size = 4},
  receive_timeout = {abs_value = 0}, ccs = COCO_NONE, max = 0,
  ignore_shutdown = 1, port = 12147, persist = 0}
(gdb) print have
$7 = 0
(gdb) print ret
$8 = 1

Christian Grothoff

2011-10-22 22:24

manager   ~0004724

(gdb) bt full
#0 0x000000080076e77c in GNUNET_NETWORK_get_fd (desc=0x0) at network.c:891
No locals.
#1 0x000000080077a871 in GNUNET_SCHEDULER_add_write_net (delay=
      {rel_value = 1778}, wfd=0x0, task=0x800756360 <transmit_ready>,
    task_cls=0x80141b0c0) at scheduler.c:1482
    __FUNCTION__ = "GNUNET_SCHEDULER_add_write_net"
    log_call_enabled = -1
#2 0x0000000800756ca9 in transmit_ready (cls=0x80141b0c0, tc=0x7fffffffe420)
    at connection.c:1608
    sock = (struct GNUNET_CONNECTION_Handle *) 0x80141b0c0
    notify = 0x3e800778bd0
    ret = 1
    have = 0

Christian Grothoff

2011-10-22 22:27

manager   ~0004725

(gdb) print *tc
$9 = {reason = 3, read_ready = 0x801416080, write_ready = 0x801416110}

Christian Grothoff

2011-10-22 22:29

manager   ~0004726

Reason 3 is SHUTDOWN + TIMEOUT. At the same time, the 'ignore_shutdown' flag is set, hence the goto in line 1499 jumps over the 'sock->sock != NULL' assertion and into the NULL-deref later.

Note: This is the 'gnunet-arm -eq' process.

Christian Grothoff

2011-10-22 22:36

manager   ~0004727

arm_api is the only code that sets the ignore_shutdown flag. The reason is that a service using arm_api to communicate with ARM probably doesn't want to see that communication interrupted due to a shutdown by ARM.

Hence this code is likely not tested much (bug in connection.c in this case; not sure what we should do if 'sock->sock' is NULL, and we're ready due to shutdown AND we're supposed to ignore shutdown). How on earth did we get into this situation in the first place? The scheduler must have been waiting on some non-NULL socket before! (Did the socket get destroyed and the task not aborted?)

Why does this problem arise here on FreeBSD? (gnunet-service-arm failed to terminate and then the buildbot killed gnunet-arm via signal!? if so, why did gnunet-arm's timeout not kick in? or did it? in any case, why gnunet-arm got a shutdown likely relates to why the testcase is failing -> possibly another issue).

Christian Grothoff

2011-10-23 10:40

manager   ~0004728

Fixed in SVN 17678--17681 (got rid of ignore-shutdown, fixed hanging task in testing, longer NSE interval to avoid CPU-starvation of connect process).

Issue History

Date ModifiedUsernameFieldChange
2011-10-22 22:20Christian GrothoffNew Issue
2011-10-22 22:20Christian GrothoffStatusnew => assigned
2011-10-22 22:20Christian GrothoffAssigned To => Christian Grothoff
2011-10-22 22:24Christian GrothoffNote Added: 0004723
2011-10-22 22:24Christian GrothoffNote Added: 0004724
2011-10-22 22:27Christian GrothoffNote Added: 0004725
2011-10-22 22:29Christian GrothoffNote Added: 0004726
2011-10-22 22:36Christian GrothoffNote Added: 0004727
2011-10-23 10:40Christian GrothoffNote Added: 0004728
2011-10-23 10:40Christian GrothoffStatusassigned => resolved
2011-10-23 10:40Christian GrothoffFixed in Version => 0.9.0pre4
2011-10-23 10:40Christian GrothoffResolutionopen => fixed
2011-10-31 11:00Christian GrothoffStatusresolved => closed