View Issue Details

IDProjectCategoryView StatusLast Update
0004870GNUnetcadet servicepublic2018-06-07 00:24
Reporterlurchi Assigned ToChristian Grothoff  
PrioritynormalSeveritycrashReproducibilityalways
Status closedResolutionfixed 
OSDebianOS Version8.6 
Product VersionGit master 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0004870: new CADET service crashes when using gnunet-cadet
DescriptionI'm on current HEAD (dc430a9d23f8fd76f700d6836d4f4748429d70cd) and trying to establish a connection with gnunet-cadet between two VMs. No message about an incoming connection is displayed. Instead I see on both peers:

ERROR Assertion failed at gnunet-service-cadet-new_paths.c:79

coredump and config file is attached. The coredump is from the connecting peer, but on the listening peer it looks identical.
Steps To Reproducelisten on one peer: gnunet-cadet -o 8888
try to connect from other peer:
gnunet-cadet W1XWMKG97X1388GBY7F8MYZHJ8QXV1D8DENS4Z4G8ZW2EV22WWEG 8888
wait a few seconds
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

[conversation]
LINE = 2
TagsNo tags attached.
Attached Files
core.32675 (643,072 bytes)

Activities

Christian Grothoff

2017-01-29 18:58

manager   ~0011658

Please don't attach CORE dumps, they are useless as my build will differ from yours. Instead run gdb on the binary & the core dump and run 'bt' so we get a stack trace. Or put in the valgrind-prefix and include the valgrind report.

Christian Grothoff

2017-01-29 18:59

manager   ~0011659

Oh, and the assertion on line 79 is totally harmless, it's just a reminder that something is not yet implemented.

lurchi

2017-01-29 19:05

developer   ~0011660

Ok!

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000040d68a in destroy_route (route=0x0)
    at gnunet-service-cadet-new_core.c:320
320 GNUNET_assert (route ==
(gdb) bt
#0 0x000000000040d68a in destroy_route (route=0x0)
    at gnunet-service-cadet-new_core.c:320
#1 0x000000000040e45c in handle_connection_broken (cls=0x11f0240, msg=0x1201b04)
    at gnunet-service-cadet-new_core.c:754
#2 0x00007ff1eea8e13d in GNUNET_MQ_inject_message (mq=0x1201840, mh=0x1201b04)
    at mq.c:265
#3 0x00007ff1ee632dba in handle_notify_inbound (cls=0x11eaf40, ntm=0x1201ae0)
    at core_api.c:651
#4 0x00007ff1eea8e13d in GNUNET_MQ_inject_message (mq=0x11ef2a0, mh=0x1201ae0)
    at mq.c:265
#5 0x00007ff1eea5cf2d in recv_message (cls=0x11ebc40, msg=0x1201ae0) at client.c:301
#6 0x00007ff1eea8d960 in GNUNET_MST_from_buffer (mst=0x11ef180, buf=0x0, size=0,
    purge=0, one_shot=0) at mst.c:232
#7 0x00007ff1eea8df3a in GNUNET_MST_read (mst=0x11ef180, sock=0x11ef200, purge=0,
    one_shot=0) at mst.c:359
#8 0x00007ff1eea5d3ce in receive_ready (cls=0x11ebc40) at client.c:383
#9 0x00007ff1eea9f569 in run_ready (rs=0x1200350, ws=0x12003e0) at scheduler.c:620
#10 0x00007ff1eea9fe38 in GNUNET_SCHEDULER_run (task=0x7ff1eeaae422 <service_main>,
    task_cls=0x7fff702a2590) at scheduler.c:887
#11 0x00007ff1eeab3489 in GNUNET_SERVICE_ruN_ (argc=3, argv=0x7fff702a2b18,
    service_name=0x41b09f "cadet", options=GNUNET_SERVICE_OPTION_NONE,
    service_init_cb=0x4060b9 <run>, connect_cb=0x4057a3 <client_connect_cb>,
    disconnect_cb=0x405d65 <client_disconnect_cb>, cls=0x0, handlers=0x7fff702a26f0)
    at service_new.c:1864
#12 0x0000000000406b62 in main (argc=3, argv=0x7fff702a2b18)
    at gnunet-service-cadet-new.c:1413

Christian Grothoff

2017-01-29 19:11

manager   ~0011661

Anyway, was able to reproduce, investigating now.

Christian Grothoff

2017-01-30 20:37

manager   ~0011677

Better now? We had misc. fixes...

lurchi

2017-01-31 14:48

developer   ~0011681

yes, it's fixed. Thank you!

Issue History

Date Modified Username Field Change
2017-01-29 18:56 lurchi New Issue
2017-01-29 18:56 lurchi Status new => assigned
2017-01-29 18:56 lurchi Assigned To => Christian Grothoff
2017-01-29 18:56 lurchi File Added: core.32675
2017-01-29 18:58 Christian Grothoff Note Added: 0011658
2017-01-29 18:59 Christian Grothoff Note Added: 0011659
2017-01-29 19:05 lurchi Note Added: 0011660
2017-01-29 19:11 Christian Grothoff Note Added: 0011661
2017-01-30 20:37 Christian Grothoff Note Added: 0011677
2017-01-31 14:48 lurchi Note Added: 0011681
2017-01-31 14:49 lurchi Status assigned => resolved
2017-01-31 14:49 lurchi Resolution open => fixed
2017-02-01 20:54 Christian Grothoff Fixed in Version => 0.11.0pre66
2017-02-01 20:54 Christian Grothoff Target Version => 0.11.0pre66
2018-06-07 00:24 Christian Grothoff Status resolved => closed