View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003745 | GNUnet | file-sharing service | public | 2015-03-29 18:14 | 2018-06-07 00:25 |
Reporter | amatus | Assigned To | Christian Grothoff | ||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | closed | Resolution | fixed | ||
Product Version | Git master | ||||
Target Version | 0.11.0pre66 | Fixed in Version | 0.11.0pre66 | ||
Summary | 0003745: Possible infinite loop in process_kblock_for_unindex | ||||
Description | The documentation for process_kblock_for_unindex says: Function called from datastore with result from us looking for a UBlock. There are four cases: 1) no result, means we move on to the next keyword 2) UID is the same as the first UID, means we move on to next keyword 3) UBlock for a different CHK, means we keep looking for more 4) UBlock is for our CHK, means we remove the block and then move on to the next keyword Case 2 is meant to stop iteration when roff (the offset into the matching records in the database) wraps around and returns the first UID again. This won't happen if that UID is removed from the database in the mean time. | ||||
Tags | No tags attached. | ||||
|
Ok, just moving the 'first_uid' logic to the case where we do NOT remove the block is insufficient, as a concurrent action may still remove the block. Yuck. Messy. |
|
Fixed in SVN 35487. |
Date Modified | Username | Field | Change |
---|---|---|---|
2015-03-29 18:14 | amatus | New Issue | |
2015-03-30 21:27 | Christian Grothoff | Note Added: 0009061 | |
2015-03-30 21:46 | Christian Grothoff | Note Added: 0009062 | |
2015-03-30 21:46 | Christian Grothoff | Status | new => resolved |
2015-03-30 21:46 | Christian Grothoff | Fixed in Version | => 0.11.0pre66 |
2015-03-30 21:46 | Christian Grothoff | Resolution | open => fixed |
2015-03-30 21:46 | Christian Grothoff | Assigned To | => Christian Grothoff |
2015-03-30 21:46 | Christian Grothoff | Target Version | => 0.11.0pre66 |
2018-06-07 00:25 | Christian Grothoff | Status | resolved => closed |