View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002661 | GNUnet | core service | public | 2012-11-27 21:04 | 2012-12-21 16:49 |
| Reporter | Florian Dold | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.9.5 | Fixed in Version | 0.9.5 | ||
| Summary | 0002661: calling CORE_disconnect causes assertion from container_multihashmap.c:216 | ||||
| Description | Connecting to core in the following way static const struct GNUNET_CORE_MessageHandler handlers[] = {{NULL, 0, 0}}; core = GNUNET_CORE_connect (c, NULL, &core_startup, NULL, NULL, NULL, GNUNET_NO, NULL, GNUNET_NO, handlers); and calling CORE_disconnect in the core_startup closure causes the assertion. See "Additional Information" for a stacktrace. The cause of this bug is in core_api.c/main_notify_handler. In line 796, h->peers is passed to GNUNET_CONTAINER_multihashmap_get, but is null. I don't know the intricacies of the core api implementation, so I don't dare to fix it myself. As an aside, I'm connecting to core just to get the peer identity of the peer running the service. This may or may not be the right way to do it, but the above should definitely be a bug. | ||||
| Additional Information | (gdb) backtrace #0 0x00007ffff75eb425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff75eeb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff7b8fe39 in GNUNET_abort () at common_logging.c:293 #3 0x00007ffff7b9b5aa in idx_of (map=<optimized out>, key=<optimized out>) at container_multihashmap.c:216 #4 idx_of (map=<optimized out>, key=<optimized out>) at container_multihashmap.c:213 #5 0x00007ffff7b9b7ef in GNUNET_CONTAINER_multihashmap_get (map=0x0, key=0x604848) at container_multihashmap.c:251 #6 0x00007ffff79776fc in main_notify_handler (cls=0x6047d0, msg=<optimized out>) at core_api.c:796 #7 0x00007ffff7b8d046 in receive_task (cls=0x605500, tc=<optimized out>) at client.c:597 #8 0x00007ffff7bbade0 in run_ready (ws=0x604270, rs=0x6041e0) at scheduler.c:597 #9 GNUNET_SCHEDULER_run (task=<optimized out>, task_cls=<optimized out>) at scheduler.c:785 #10 0x00007ffff7bc4077 in GNUNET_SERVICE_run (argc=4, argv=<optimized out>, service_name=0x401aa5 "consensus", options=<optimized out>, task=<optimized out>, task_cls=<optimized out>) at service.c:1813 #11 0x0000000000400b59 in main (argc=<optimized out>, argv=<optimized out>) at gnunet-service-consensus.c:414 | ||||
| Tags | No tags attached. | ||||
|
|
Not a bug in core-api, it is simply NOT allowed to call GNUNET_CORE_disconnect during the startup callback. If you want to then shutdown, you need to schedule another task to do this. I'm updating the core API documentation to clarify this. |
|
|
API clarified in SVN 25144. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-11-27 21:04 | Florian Dold | New Issue | |
| 2012-11-27 21:15 | Christian Grothoff | Note Added: 0006613 | |
| 2012-11-27 21:16 | Christian Grothoff | Note Added: 0006614 | |
| 2012-11-27 21:16 | Christian Grothoff | Status | new => resolved |
| 2012-11-27 21:16 | Christian Grothoff | Fixed in Version | => 0.9.5 |
| 2012-11-27 21:16 | Christian Grothoff | Resolution | open => fixed |
| 2012-11-27 21:16 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2012-11-27 21:16 | Christian Grothoff | Target Version | => 0.9.5 |
| 2012-12-21 16:49 | Christian Grothoff | Status | resolved => closed |
