View Issue Details

IDProjectCategoryView StatusLast Update
0002850GNUnetconsensus servicepublic2013-12-24 20:54
ReporterChristian GrothoffAssigned ToChristian Grothoff 
PriorityurgentSeveritycrashReproducibilityunable to reproduce
Status closedResolutionwon't fix 
Product VersionSVN HEAD 
Target Version0.10.0Fixed in Version0.10.0 
Summary0002850: consensus service segfaults during dv test
DescriptionMar 30 17:28:20-333973 consensus-13987 ERROR Assertion failed at gnunet-service-consensus.c:1997.
==13987== Invalid read of size 8
==13987== at 0x409571: core_startup (gnunet-service-consensus.c:2658)
==13987== by 0x50AC886: main_notify_handler (core_api.c:785)
==13987== by 0x4E433D3: receive_task (client.c:597)
==13987== by 0x4E7F988: run_ready (scheduler.c:597)
==13987== by 0x4E801D7: GNUNET_SCHEDULER_run (scheduler.c:786)
==13987== by 0x4E8F1F0: GNUNET_SERVICE_run (service.c:1816)
==13987== by 0x409964: main (gnunet-service-consensus.c:2778)
==13987== Address 0x6f87d00 is 0 bytes inside a block of size 240 free'd
==13987== at 0x4C27D4E: free (vg_replace_malloc.c:427)
==13987== by 0x4E45B7E: GNUNET_xfree_ (common_allocation.c:236)
==13987== by 0x405DFA: destroy_session (gnunet-service-consensus.c:1667)
==13987== by 0x405E3B: disconnect_client (gnunet-service-consensus.c:1688)
==13987== by 0x406EBA: initialize_session (gnunet-service-consensus.c:1998)
==13987== by 0x40956C: core_startup (gnunet-service-consensus.c:2657)
==13987== by 0x50AC886: main_notify_handler (core_api.c:785)
==13987== by 0x4E433D3: receive_task (client.c:597)
==13987== by 0x4E7F988: run_ready (scheduler.c:597)
==13987== by 0x4E801D7: GNUNET_SCHEDULER_run (scheduler.c:786)
==13987== by 0x4E8F1F0: GNUNET_SERVICE_run (service.c:1816)
==13987== by 0x409964: main (gnunet-service-consensus.c:2778)
==13987==
==13987== Invalid read of size 8
==13987== at 0x409558: core_startup (gnunet-service-consensus.c:2656)
==13987== by 0x50AC886: main_notify_handler (core_api.c:785)
==13987== by 0x4E433D3: receive_task (client.c:597)
==13987== by 0x4E7F988: run_ready (scheduler.c:597)
==13987== by 0x4E801D7: GNUNET_SCHEDULER_run (scheduler.c:786)
==13987== by 0x4E8F1F0: GNUNET_SERVICE_run (service.c:1816)
==13987== by 0x409964: main (gnunet-service-consensus.c:2778)
==13987== Address 0xdf0adba0df0adca is not stack'd, malloc'd or (recently) free'd
==13987==
==13987==
==13987== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==13987== General Protection Fault
==13987== at 0x409558: core_startup (gnunet-service-consensus.c:2656)
==13987== by 0x50AC886: main_notify_handler (core_api.c:785)
==13987== by 0x4E433D3: receive_task (client.c:597)
==13987== by 0x4E7F988: run_ready (scheduler.c:597)
==13987== by 0x4E801D7: GNUNET_SCHEDULER_run (scheduler.c:786)
==13987== by 0x4E8F1F0: GNUNET_SERVICE_run (service.c:1816)
==13987== by 0x409964: main (gnunet-service-consensus.c:2778)
==13987==
Steps To ReproduceRun 'make check' in src/dv/. The second test will trigger the crash.
TagsNo tags attached.

Relationships

child of 0001795 confirmed DV is not implemented 

Activities

Florian Dold

2013-03-30 22:50

developer   ~0007021

Obviously the segfault is a problem with consensus.

However, the session id that dv currently uses for consensus only depends on the two reconciling neighbors.

Thus, if dv repeats the consensus, it should use another session id, and not join the old session, as the consensus service may not destroy a session right after the local client has left, but only after a timeout.

Of course this behavior is not necessary for 2-peer consensus, so it might be an option to add this as a special case to destroy the session once the local client leaves in a 2-peer consensus. Would this be preferable?

Christian Grothoff

2013-03-30 22:53

manager   ~0007022

How is that timeout until the service forgets about the existing session determined? Unless clocks are synchronized, I don't have a good way to generate fresh session IDs each time.

Also, yes, this is only a 2-peer consensus; still, obviously the 2nd peer might take a tiny bit longer (one last 'finish' message or something). In any case, you are right in that for 2-peer consensus, you ought to be able to destroy the session much faster, and that would be good and would help.

Christian Grothoff

2013-06-03 13:16

manager   ~0007147

Current version of DV no longer uses consensus, and consensus has changed dramatically, so this report is no longer relevant.

Issue History

Date Modified Username Field Change
2013-03-30 17:30 Christian Grothoff New Issue
2013-03-30 17:30 Christian Grothoff Status new => assigned
2013-03-30 17:30 Christian Grothoff Assigned To => Florian Dold
2013-03-30 17:31 Christian Grothoff Relationship added child of 0001795
2013-03-30 22:50 Florian Dold Note Added: 0007021
2013-03-30 22:53 Christian Grothoff Note Added: 0007022
2013-04-16 13:45 Christian Grothoff Category Consensus service => consensus service
2013-06-03 13:16 Christian Grothoff Note Added: 0007147
2013-06-03 13:16 Christian Grothoff Assigned To Florian Dold => Christian Grothoff
2013-06-03 13:16 Christian Grothoff Reproducibility always => unable to reproduce
2013-06-03 13:16 Christian Grothoff Resolution open => won't fix
2013-06-03 13:16 Christian Grothoff Fixed in Version => 0.10.0
2013-06-03 13:16 Christian Grothoff Target Version => 0.10.0
2013-06-03 13:16 Christian Grothoff Status assigned => resolved
2013-12-24 20:54 Christian Grothoff Status resolved => closed