View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003719GNUnettransport servicepublic2015-03-17 16:242019-02-28 11:17
Reporteramatus Assigned ToChristian Grothoff  
PrioritynormalSeveritycrashReproducibilityunable to reproduce
Status closedResolutionfixed 
Product VersionGit master 
Target Version0.11.0Fixed in Version0.11.0 
Summary0003719: GNUNET_assert (NULL == ai); failed in rev 35365
DescriptionMar 16 12:15:27-080406 transport-16950 ERROR Assertion failed at gnunet-service-transport_ats.c:467.
Additional InformationProgram terminated with signal SIGABRT, Aborted.
#0 0x00007f04565fc107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007f04565fc107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f04565fd4e8 in __GI_abort () at abort.c:89
#2 0x00007f0456c88a7e in GNUNET_abort_ () at common_logging.c:289
#3 0x0000000000406af1 in GST_ats_add_address (address=0x2b9c660, prop=0x7ffc355865c0)
    at gnunet-service-transport_ats.c:467
#4 0x000000000041c84b in GST_validation_handle_pong (sender=0x2ba3030, hdr=0x7ffc35586948)
    at gnunet-service-transport_validation.c:1501
#5 0x000000000040476a in GST_receive_callback (cls=0x25cde60, address=0x2ba3030, session=0x2e7acd0,
    message=0x7ffc35586948) at gnunet-service-transport.c:423
#6 0x000000000041db3f in GST_manipulation_recv (cls=0x25cde60, address=0x2ba3030, session=0x2e7acd0,
    message=0x7ffc35586948) at gnunet-service-transport_manipulation.c:412
#7 0x00007f04512942c1 in process_inbound_tokenized_messages (cls=0x2640070, client=0x2e7acd0,
    hdr=0x7ffc35586948) at plugin_transport_udp.c:2139
#8 0x00007f0456cc6468 in GNUNET_SERVER_mst_receive (mst=0x263e1d0, client_identity=0x2e7acd0,
    buf=0x7ffc35586948 "", size=106, purge=1, one_shot=0) at server_mst.c:262
#9 0x00007f04512950fa in process_udp_message (plugin=0x2640070, msg=0x7ffc35586920,
    udp_addr=0x7ffc35586910, udp_addr_len=10, network_type=GNUNET_ATS_NET_WAN)
    at plugin_transport_udp.c:2533
#10 0x00007f0451295fea in udp_select_read (plugin=0x2640070, rsock=0x25f48c0)
    at plugin_transport_udp.c:2934
#11 0x00007f04512969ad in udp_plugin_select_v4 (cls=0x2640070, tc=0x7ffc35596a60)
    at plugin_transport_udp.c:3264
#12 0x00007f0456cbf73b in run_ready (rs=0x25e0a00, ws=0x25cb960) at scheduler.c:587
#13 0x00007f0456cbffcf in GNUNET_SCHEDULER_run (task=0x7f0456ccb546 <service_task>,
    task_cls=0x7ffc35596df0) at scheduler.c:867
#14 0x00007f0456ccd16e in GNUNET_SERVICE_run (argc=7, argv=0x7ffc35597078,
    service_name=0x41eb6c "transport", options=GNUNET_SERVICE_OPTION_NONE, task=0x405662 <run>,
    task_cls=0x0) at service.c:1503
#15 0x0000000000405c29 in main (argc=7, argv=0x7ffc35597078) at gnunet-service-transport.c:929
(gdb) f 3
#3 0x0000000000406af1 in GST_ats_add_address (address=0x2b9c660, prop=0x7ffc355865c0)
    at gnunet-service-transport_ats.c:467
467 GNUNET_assert (NULL == ai);
(gdb) p *address
$1 = {peer = {public_key = {
      q_y = "\200\337\061i\n\245\244\b\224\246\277]\355\351\334 \022\273\016q\263 \224\353f6\321_+!\233\271"}}, transport_name = 0x2b9c6aa "udp", address = 0x2b9c6a0, address_length = 10,
  local_info = GNUNET_HELLO_ADDRESS_INFO_NONE}
TagsNo tags attached.

Relationships

related to 0003690 closedChristian Grothoff Assertion failed at gnunet-service-transport_ats.c:306. NULL == ai 

Activities

Christian Grothoff

2015-05-01 10:38

manager   ~0009111

Matthias, are you looking into this one?

Christian Grothoff

2015-05-20 18:21

manager   ~0009139

Ok, theory (base case):

1) verifier starts UDP verification, UDP sends PING
2) UDP receives PONG, starts session (which adds address)
3) verifier receives PONG, adds address again => kaboom.

But that can't be right, as then it would ALWAYS crash.

So possibility two A (good execution):

1) verifier starts UDP verification, creates session to send PING
2) UDP receives PONG, re-uses EXISTING session (which does not add address)
3) verifier receives PONG, adds address (all good)

and possibility two B (bad execution):

1) verifier starts UDP verification, creates session to send PING
1b) original SESSION times out, THEN the peer replies
2) UDP receives PONG, creates FRESH (which does add address)
3) verifier receives PONG, adds address again (caboom)

The timeout explains why this would be rare.

For unix/tcp/http/https transports, this would not happen as for a bi-directional session we're again very unlikely to see a PONG on a fresh session, and if we did the incoming address would have 'incoming' in it and thus not be the same as the outgoing address (and hence no caboom).

Christian Grothoff

2015-05-20 19:19

manager   ~0009140

Index: plugin_transport_udp.c
===================================================================
--- plugin_transport_udp.c (revision 35758)
+++ plugin_transport_udp.c (working copy)
@@ -2511,7 +2511,7 @@
                                            PLUGIN_NAME,
                                            udp_addr,
                                            udp_addr_len,
- GNUNET_HELLO_ADDRESS_INFO_NONE);
+ GNUNET_HELLO_ADDRESS_INFO_INBOUND);
   if (NULL ==
       (s = udp_plugin_lookup_session (plugin,
                                       address)))
Index: plugin_transport_wlan.c
===================================================================
--- plugin_transport_wlan.c (revision 35758)
+++ plugin_transport_wlan.c (working copy)
@@ -1481,7 +1481,7 @@
                                              PLUGIN_NAME,
                                              &mas->endpoint->wlan_addr,
                                              sizeof (mas->endpoint->wlan_addr),
- GNUNET_HELLO_ADDRESS_INFO_NONE);
+ GNUNET_HELLO_ADDRESS_INFO_INBOUND);
     mas->session = lookup_session (mas->endpoint,
                                    &tmpsource);
     if (NULL == mas->session)
@@ -1609,7 +1609,7 @@
                                                PLUGIN_NAME,
                                                &mas->endpoint->wlan_addr,
                                                sizeof (struct WlanAddress),
- GNUNET_HELLO_ADDRESS_INFO_NONE);
+ GNUNET_HELLO_ADDRESS_INFO_INBOUND);
       plugin->env->session_start (plugin->env->cls,
                                   address,
                                   mas->session,
grothoff@pixel:~/svn/gnunet/src/transport$ svn commit -m "set inbound flag which should fix 0003719 (assuming diagnostic is correct) at the expense of having two session objects for what is pretty much the same address; however, as the inbound one is not really validated and might not work due to NAT, this actually does make sense"
Sending plugin_transport_udp.c
Sending plugin_transport_wlan.c
Transmitting file data ..
Committed revision 35762.

Christian Grothoff

2015-05-20 19:19

manager   ~0009141

Hopefully fixed, assuming diagnostic was right.

Christian Grothoff

2015-05-21 11:12

manager   ~0009143

Diagnostic might have been right, but fix doesn't work (existing hello cmp failed to compare local_options, if we add that, we don't find sessions for ACKs due to missmatch in that flag as we now have 2 sessions). Yuck.

Christian Grothoff

2015-05-21 11:24

manager   ~0009144

Looking again at the code, I cannot find why I thought

2) UDP receives PONG, creates FRESH (which does add address)

was possible. If the INBOUND flag is NOT set, the adding of the address doesn't happen on receiving, which means that code path doesn't run as far as I can tell. So keeping the flag at NONE (SVN 35764) as it was should mean the (B)ad case can't happen. Oddly enough, those checks were already in place when the bug was reported, so this still doesn't explain it. :-(

Christian Grothoff

2015-05-21 11:35

manager   ~0009146

Setting to feedback as I'd really like to first be able to reproduce this. Also, would probably be helpful to see what the contents of address and ai->address at the crash site are.

Christian Grothoff

2019-01-27 12:03

manager   ~0013477

Calling this resolved for now, as (presumably) not reproduced since the "fix".

Issue History

Date Modified Username Field Change
2015-03-17 16:24 amatus New Issue
2015-03-17 16:24 amatus Status new => assigned
2015-03-17 16:24 amatus Assigned To => Matthias Wachs
2015-03-17 16:25 amatus Relationship added related to 0003690
2015-03-20 21:22 Christian Grothoff Target Version => 0.11.0pre66
2015-05-01 10:38 Christian Grothoff Note Added: 0009111
2015-05-18 21:40 Christian Grothoff Assigned To Matthias Wachs => Christian Grothoff
2015-05-20 18:21 Christian Grothoff Note Added: 0009139
2015-05-20 19:19 Christian Grothoff Note Added: 0009140
2015-05-20 19:19 Christian Grothoff Note Added: 0009141
2015-05-20 19:19 Christian Grothoff Status assigned => resolved
2015-05-20 19:19 Christian Grothoff Fixed in Version => 0.11.0pre66
2015-05-20 19:19 Christian Grothoff Resolution open => fixed
2015-05-21 11:12 Christian Grothoff Note Added: 0009143
2015-05-21 11:12 Christian Grothoff Status resolved => assigned
2015-05-21 11:24 Christian Grothoff Note Added: 0009144
2015-05-21 11:26 Christian Grothoff Assigned To Christian Grothoff =>
2015-05-21 11:26 Christian Grothoff Reproducibility have not tried => unable to reproduce
2015-05-21 11:26 Christian Grothoff Status assigned => acknowledged
2015-05-21 11:26 Christian Grothoff Resolution fixed => open
2015-05-21 11:26 Christian Grothoff Fixed in Version 0.11.0pre66 =>
2015-05-21 11:26 Christian Grothoff Target Version 0.11.0pre66 =>
2015-05-21 11:35 Christian Grothoff Note Added: 0009146
2015-05-21 11:35 Christian Grothoff Status acknowledged => feedback
2017-02-26 02:16 Christian Grothoff Target Version => 0.11.0
2019-01-27 12:03 Christian Grothoff Assigned To => Christian Grothoff
2019-01-27 12:03 Christian Grothoff Status feedback => resolved
2019-01-27 12:03 Christian Grothoff Resolution open => fixed
2019-01-27 12:03 Christian Grothoff Fixed in Version => 0.11.0
2019-01-27 12:03 Christian Grothoff Note Added: 0013477
2019-02-28 11:17 Christian Grothoff Status resolved => closed