View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009246 | GNUnet | transport service | public | 2024-10-03 00:25 | 2024-11-14 09:43 |
| Reporter | thejackimonster | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | new | Resolution | open | ||
| Product Version | Git master | ||||
| Target Version | 0.23.0 | ||||
| Summary | 0009246: Virtual links are still in memory during shutdown | ||||
| Description | While testing around making connections between multiple peers I tripped following assertion: ERROR Assertion failed at gnunet-service-transport.c:12926 It states that the multipeermap containing the virtual links (potentially of neighbours) should be empty during shutdown. However it isn't always empty. So I tried to solve it via following commit because I thought the visibility task was keeping them alive during cleanup: https://git.gnunet.org/gnunet.git/commit/?id=d384ca1cb91f1f3482b28f576bd91e9c85ecf6b6 Seems like that's not the only thing causing this. Because I was still able to trigger the assert after my changes. | ||||
| Steps To Reproduce | - Startup peer (gnunet-arm -s) - Wait for established connections to other peers (gnunet-core -s) - Open a connection via cadet to another peer (gnunet-cadet) - Stop all services (gnunet-arm -e) | ||||
| Additional Information | I guess as workaround we could iterate through all remaining links and free them. But I assumed the assert had the reason to potentially catch errors in other parts of the code. So I only made changes to freeing the neighbours, not starting any more visibility tasks during shutdown. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-10-03 00:25 | thejackimonster | New Issue | |
| 2024-11-10 10:46 | schanzen | Target Version | => 0.22.3 |
| 2024-11-14 09:43 | schanzen | Target Version | 0.22.3 => 0.23.0 |
