View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004985GNUnetcadet servicepublic2017-04-11 10:362018-06-07 00:24
Reporterlurchi Assigned ToChristian Grothoff  
PrioritynormalSeveritymajorReproducibilityrandom
Status closedResolutionfixed 
OSDebian 
Product VersionGit master 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0004985: conversation service causes: ERROR Assertion failed at cadet_api.c:1617
DescriptionSometimes when I try to accept a call in gnunet-conversation an error occurs in GNUNET_CADET_open_port. The backtrace is attached.

revision: b95646624c640ac3f1ed74d5474b090f46af745c
Additional Information[arm]
SYSTEM_ONLY = NO
USER_ONLY = NO

[hostlist]
AUTOSTART = NO
FORCESTART = NO

#[topology]
#FRIENDS-ONLY = YES

[peerinfo]
USE_INCLUDED_HELLOS = NO

[transport-udp]
BROADCAST = NO

[fs]
AUTOSTART = NO
FORCESTART = NO

[nse]
FORCESTART = NO

[set]
FORCESTART = NO

[statistics]
FORCESTART = NO

[vpn]
FORCESTART = NO

[PATHS]
GNUNET_HOME = ./test

[nat]
ENABLE_UPNP = NO

[conversation]
LINE = 2
TagsNo tags attached.
Attached Files
20170411.txt (1,793 bytes)    
(gdb) bt
#0  0x00007f108c0e5067 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f108c0e6448 in __GI_abort () at abort.c:89
#2  0x00007f108c77f600 in GNUNET_abort_ () at common_logging.c:293
#3  0x00007f108c9ed18d in GNUNET_CADET_open_port (h=0x1123b50, port=0x1123978, 
    connects=0x404aaa <inbound_channel>, connects_cls=0x1124800, window_changes=0x0, 
    disconnects=0x403f85 <inbound_end>, handlers=0x7ffe0f8ecc30) at cadet_api.c:1613
#4  0x000000000040520a in handle_client_register_message (cls=0x1124800, msg=0x1123970)
    at gnunet-service-conversation.c:1267
#5  0x00007f108c7a99a5 in GNUNET_MQ_inject_message (mq=0x1124650, mh=0x1123970)
    at mq.c:252
#6  0x00007f108c7c6774 in service_client_mst_cb (cls=0x1124260, message=0x1123970)
    at service.c:2119
#7  0x00007f108c7a9021 in GNUNET_MST_from_buffer (mst=0x1124380, buf=0x0, size=0, 
    purge=0, one_shot=-1) at mst.c:232
#8  0x00007f108c7a970a in GNUNET_MST_read (mst=0x1124380, sock=0x1123740, purge=0, 
    one_shot=1) at mst.c:359
#9  0x00007f108c7c67d7 in service_client_recv (cls=0x1124260) at service.c:2140
#10 0x00007f108c7bc436 in run_ready (rs=0x1138160, ws=0x11381f0) at scheduler.c:670
#11 0x00007f108c7bcd7c in GNUNET_SCHEDULER_run (task=0x7f108c7c063c <service_main>, 
    task_cls=0x7ffe0f8ed400) at scheduler.c:937
#12 0x00007f108c7c576f in GNUNET_SERVICE_run_ (argc=3, argv=0x7ffe0f8ed868, 
    service_name=0x405f73 "conversation", options=GNUNET_SERVICE_OPTION_NONE, 
    service_init_cb=0x40525f <run>, connect_cb=0x404d51 <client_connect_cb>, 
    disconnect_cb=0x404d9b <client_disconnect_cb>, cls=0x0, handlers=0x7ffe0f8ed560)
    at service.c:1846
#13 0x0000000000405769 in main (argc=3, argv=0x7ffe0f8ed868)
    at gnunet-service-conversation.c:1325
20170411.txt (1,793 bytes)   

Activities

Christian Grothoff

2017-04-11 11:38

manager   ~0012031

This happens if two clients open the same line / port. This is not allowed, as then we don't know which one should handle the incoming request. However, we obviously should not crash but instead print a warning and refuse the new client. Fixed in 2b3d804ab..51e9f26b1

Issue History

Date Modified Username Field Change
2017-04-11 10:36 lurchi New Issue
2017-04-11 10:36 lurchi Status new => assigned
2017-04-11 10:36 lurchi Assigned To => Christian Grothoff
2017-04-11 10:36 lurchi File Added: 20170411.txt
2017-04-11 11:38 Christian Grothoff Status assigned => resolved
2017-04-11 11:38 Christian Grothoff Resolution open => fixed
2017-04-11 11:38 Christian Grothoff Fixed in Version => 0.11.0pre66
2017-04-11 11:38 Christian Grothoff Note Added: 0012031
2017-04-11 11:38 Christian Grothoff Target Version => 0.11.0pre66
2018-06-07 00:24 Christian Grothoff Status resolved => closed