View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001713 | GNUnet | core service | public | 2011-06-17 16:00 | 2011-10-31 12:00 |
| Reporter | mrwiggles | Assigned To | Christian Grothoff | ||
| Priority | low | Severity | minor | Reproducibility | random |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Summary | 0001713: Core queue full | ||||
| Description | Core assertion failure due to full queue... I'm not sure why this condition shouldn't happen, but there's a comment in the code that says it shouldn't. Jun 17 13:37:22 core-10546 ERROR Assertion failed at gnunet-service-core.c:2879. Jun 17 13:39:31 core-10546 ERROR Assertion failed at gnunet-service-core.c:2879. Jun 17 13:40:36 core-10546 ERROR Assertion failed at gnunet-service-core.c:2879 | ||||
| Tags | No tags attached. | ||||
|
|
Queue overflow in the core should no longer happen because core_api.c is supposed to ask core if it is ready to accept a message for delivery, and then only transmit it to core AFTER core said "yes, I have space". |
|
|
Happened again on a buildbot (during DHT multipeer test): 17:27:19-020905 core-25162 ERROR Assertion failed at gnunet-service-core.c:2901 |
|
|
Got a possible lead on the problem. schedule_peer_messages sends out the 'SendMessageReady' to the client. The code only counts the current number of messages in the queue and does not look at the queue of (control) messages to the client. So suppose the client send us 15 requests, and got a 'ready' for each of them (since 15 is fine). Then we get a 16th request, at which point we'd not send a 'ready'. Then, 'discard_expired_messages' discards the TWO message from the queue (so we're back to 14) and ALSO calls 'schedule_peer_messages'. Then, each of these messages generates a SECOND 'SendMessageReady' (now there are 2 of them in the queue to the client). The client can then read the first ready, give us another message (queue size: 15), we generate another 'ready' (2 ready in queue to client), client sends another message (queue size: 16), we do NOT generate another ready (but there is 1 ready left in message queue), client sends another message, gnunet-service-core bitches because the queue size would now be 17 > 16. |
|
|
Solutions: couple of possible ways to fix it: 1) When discarding 'expired' messages, only generate SendMessageReady's if the last message received from the client was not responded to yet (simple to do: test if the queue was completely FULL prior to the discard). 2) maintain a count on 'outstanding' Ready-solicitations I think (1) is simple enough... |
|
|
Fixed in SVN 17149. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-06-17 16:00 | mrwiggles | New Issue | |
| 2011-06-17 16:14 | Christian Grothoff | Note Added: 0004424 | |
| 2011-06-17 16:23 | Christian Grothoff | Note Edited: 0004424 | |
| 2011-06-17 19:54 | Christian Grothoff | Summary | Core queue full (may not be a bug!) => Core queue full |
| 2011-06-17 19:54 | Christian Grothoff | Status | new => acknowledged |
| 2011-06-23 12:58 | Christian Grothoff | Priority | normal => low |
| 2011-10-02 21:54 | Christian Grothoff | Note Added: 0004665 | |
| 2011-10-03 00:10 | Christian Grothoff | Note Added: 0004667 | |
| 2011-10-03 00:13 | Christian Grothoff | Note Added: 0004668 | |
| 2011-10-03 00:16 | Christian Grothoff | Note Added: 0004669 | |
| 2011-10-03 00:16 | Christian Grothoff | Status | acknowledged => resolved |
| 2011-10-03 00:16 | Christian Grothoff | Resolution | open => fixed |
| 2011-10-03 00:16 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2011-10-04 13:21 | Christian Grothoff | Target Version | => 0.9.0pre4 |
| 2011-10-31 12:00 | Christian Grothoff | Status | resolved => closed |
