View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003719GNUnettransport servicepublic2015-03-17 15:242019-02-28 10:17
Reporteramatus Assigned ToChristian Grothoff Due Date
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 08:38

manager   ~0009111

Matthias, are you looking into this one?

Christian Grothoff

2015-05-20 16: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 17: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 17:19

manager   ~0009141

Hopefully fixed, assuming diagnostic was right.

Christian Grothoff

2015-05-21 09: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 09: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 09: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 11:03

manager   ~0013477

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

Issue History

Date ModifiedUsernameFieldChange
2015-03-17 15:24amatusNew Issue
2015-03-17 15:24amatusStatusnew => assigned
2015-03-17 15:24amatusAssigned To => Matthias Wachs
2015-03-17 15:25amatusRelationship addedrelated to 0003690
2015-03-20 20:22Christian GrothoffTarget Version => 0.11.0pre66
2015-05-01 08:38Christian GrothoffNote Added: 0009111
2015-05-18 19:40Christian GrothoffAssigned ToMatthias Wachs => Christian Grothoff
2015-05-20 16:21Christian GrothoffNote Added: 0009139
2015-05-20 17:19Christian GrothoffNote Added: 0009140
2015-05-20 17:19Christian GrothoffNote Added: 0009141
2015-05-20 17:19Christian GrothoffStatusassigned => resolved
2015-05-20 17:19Christian GrothoffFixed in Version => 0.11.0pre66
2015-05-20 17:19Christian GrothoffResolutionopen => fixed
2015-05-21 09:12Christian GrothoffNote Added: 0009143
2015-05-21 09:12Christian GrothoffStatusresolved => assigned
2015-05-21 09:24Christian GrothoffNote Added: 0009144
2015-05-21 09:26Christian GrothoffAssigned ToChristian Grothoff =>
2015-05-21 09:26Christian GrothoffReproducibilityhave not tried => unable to reproduce
2015-05-21 09:26Christian GrothoffStatusassigned => acknowledged
2015-05-21 09:26Christian GrothoffResolutionfixed => open
2015-05-21 09:26Christian GrothoffFixed in Version0.11.0pre66 =>
2015-05-21 09:26Christian GrothoffTarget Version0.11.0pre66 =>
2015-05-21 09:35Christian GrothoffNote Added: 0009146
2015-05-21 09:35Christian GrothoffStatusacknowledged => feedback
2017-02-26 01:16Christian GrothoffTarget Version => 0.11.0
2019-01-27 11:03Christian GrothoffAssigned To => Christian Grothoff
2019-01-27 11:03Christian GrothoffStatusfeedback => resolved
2019-01-27 11:03Christian GrothoffResolutionopen => fixed
2019-01-27 11:03Christian GrothoffFixed in Version => 0.11.0
2019-01-27 11:03Christian GrothoffNote Added: 0013477
2019-02-28 10:17Christian GrothoffStatusresolved => closed