View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002850 | GNUnet | consensus service | public | 2013-03-30 16:30 | 2013-12-24 19:54 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | Due Date | |
| Priority | urgent | Severity | crash | Reproducibility | unable to reproduce |
| Status | closed | Resolution | won't fix | ||
| Product Version | Git master | ||||
| Target Version | 0.10.0 | Fixed in Version | 0.10.0 | ||
| Summary | 0002850: consensus service segfaults during dv test | ||||
| Description | Mar 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 Reproduce | Run 'make check' in src/dv/. The second test will trigger the crash. | ||||
| Tags | No tags attached. | ||||
| 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? | |
| 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. | |
| Current version of DV no longer uses consensus, and consensus has changed dramatically, so this report is no longer relevant. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-03-30 16:30 | Christian Grothoff | New Issue | |
| 2013-03-30 16:30 | Christian Grothoff | Status | new => assigned |
| 2013-03-30 16:30 | Christian Grothoff | Assigned To | => Florian Dold |
| 2013-03-30 16:31 | Christian Grothoff | Relationship added | child of 0001795 |
| 2013-03-30 21:50 | Florian Dold | Note Added: 0007021 | |
| 2013-03-30 21:53 | Christian Grothoff | Note Added: 0007022 | |
| 2013-04-16 11:45 | Christian Grothoff | Category | Consensus service => consensus service |
| 2013-06-03 11:16 | Christian Grothoff | Note Added: 0007147 | |
| 2013-06-03 11:16 | Christian Grothoff | Assigned To | Florian Dold => Christian Grothoff |
| 2013-06-03 11:16 | Christian Grothoff | Reproducibility | always => unable to reproduce |
| 2013-06-03 11:16 | Christian Grothoff | Resolution | open => won't fix |
| 2013-06-03 11:16 | Christian Grothoff | Fixed in Version | => 0.10.0 |
| 2013-06-03 11:16 | Christian Grothoff | Target Version | => 0.10.0 |
| 2013-06-03 11:16 | Christian Grothoff | Status | assigned => resolved |
| 2013-12-24 19:54 | Christian Grothoff | Status | resolved => closed |