View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001838GNUnetARM servicepublic2011-10-23 00:202011-10-31 12:00
ReporterChristian Grothoff Assigned ToChristian Grothoff  
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-23 00: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-23 00: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-23 00:27

manager   ~0004725

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

Christian Grothoff

2011-10-23 00: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-23 00: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 12: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 Modified Username Field Change
2011-10-23 00:20 Christian Grothoff New Issue
2011-10-23 00:20 Christian Grothoff Status new => assigned
2011-10-23 00:20 Christian Grothoff Assigned To => Christian Grothoff
2011-10-23 00:24 Christian Grothoff Note Added: 0004723
2011-10-23 00:24 Christian Grothoff Note Added: 0004724
2011-10-23 00:27 Christian Grothoff Note Added: 0004725
2011-10-23 00:29 Christian Grothoff Note Added: 0004726
2011-10-23 00:36 Christian Grothoff Note Added: 0004727
2011-10-23 12:40 Christian Grothoff Note Added: 0004728
2011-10-23 12:40 Christian Grothoff Status assigned => resolved
2011-10-23 12:40 Christian Grothoff Fixed in Version => 0.9.0pre4
2011-10-23 12:40 Christian Grothoff Resolution open => fixed
2011-10-31 12:00 Christian Grothoff Status resolved => closed