View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009246 | GNUnet | transport service | public | 2024-10-03 00:25 | 2024-12-09 18:03 |
| Reporter | thejackimonster | Assigned To | thejackimonster | ||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.23.0 | Fixed in 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. | ||||
|
|
I think the problem is that neighbour->vl is not really populated at any point. The solution is to either cleanup links or to add it to the neighbour->vl field appropriately. I am a bit confused myself. This is sphaghetti code... especially DV |
|
|
Attempted a fix in 40d1433b8..d81aca3af I think it is necessary to cleanup both neighbours and DV entities in order to make sure the VLs are cleaned up implicitly. |
|
|
No response closing for now. |
|
|
Released |
| 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 |
| 2024-11-28 08:35 | schanzen | Note Added: 0023768 | |
| 2024-11-28 09:31 | schanzen | Changeset attached | => gnunet master d81aca3a |
| 2024-11-28 09:32 | schanzen | Assigned To | => schanzen |
| 2024-11-28 09:32 | schanzen | Status | new => feedback |
| 2024-11-28 09:32 | schanzen | Note Added: 0023769 | |
| 2024-11-30 16:41 | schanzen | Assigned To | schanzen => thejackimonster |
| 2024-12-09 17:02 | schanzen | Status | feedback => resolved |
| 2024-12-09 17:02 | schanzen | Resolution | open => fixed |
| 2024-12-09 17:02 | schanzen | Fixed in Version | => 0.23.0 |
| 2024-12-09 17:02 | schanzen | Note Added: 0023819 | |
| 2024-12-09 18:03 | schanzen | Note Added: 0023843 | |
| 2024-12-09 18:03 | schanzen | Status | resolved => closed |
