View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008978 | GNUnet | util library | public | 2024-06-25 13:23 | 2024-10-10 08:20 |
| Reporter | thejackimonster | Assigned To | thejackimonster | Due Date | |
| Priority | normal | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Fixed in Version | 0.22.1 | ||||
| Summary | 0008978: Scheduler: ready_count underflow | ||||
| Description | During testing of the new voice chat feature in messenger-gtk I ran into a crash caused by the scheduler. An assertion shut it down because of an underflow of the `ready_count` variable. I'm not sure how this is possible but it seems that during some decrement of it, it may happen. It might be caused by multiple threads accessing the GNUnet APIs. But I'm not 100% sure about this because I can't reproduce a backtrace that hints to that yet. | ||||
| Steps To Reproduce | The upstream version of messenger-gtk runs into this issue during a voice call at times. The application just crashes because of the assertion that assumes `ready_count` in the scheduler would need to be zero when the task queues are all empty. However it seems possible that an underflow hits it to the value 4294967295. | ||||
| Additional Information | Assertion that triggers the crash: https://git.gnunet.org/gnunet.git/tree/src/lib/util/scheduler.c#n2084 Locations of decrement: https://git.gnunet.org/gnunet.git/tree/src/lib/util/scheduler.c#n1033 https://git.gnunet.org/gnunet.git/tree/src/lib/util/scheduler.c#n2095 Messenger-GTK: https://git.gnunet.org/messenger-gtk.git/ | ||||
| Tags | No tags attached. | ||||
| Okay, so I tried to remove multiple threads as cause by using the code from gnunet-gtk to combine GNUnet scheduler and g_main_loop from GTK. But I could still reproduce the issue, triggering the assertion. I'm not sure how this is possible in a single-threaded environment but it looks like it is. So there's definitely something wrong in the scheduler logic. | |
| I think I found the actual cause of `ready_count` being wrong. The internal function `remove_pass_end_marker()` removed a task from the ready queue while not adjusting the `ready_count`. So I patched this: https://git.gnunet.org/gnunet.git/commit/?id=2dc422a9652b90c4c6e472aa4e7e349c77aa8098 The scheduler test case also used a workaround for this existing issue, verifying a wrong `ready_count` as accurate... | |
| I can still run into the same assertion crashing my application after those changes. So I'm still investigating. | |
| From my testing today it seems like the issue was coming from GStreamer running on a separate thread as the GNUnet scheduler. After synchronizing the pulled sample data with the scheduler thread, I was able to write it via messaging without reproducing the crash so far. I'll keep this issue open for now but it seems like the cause has been found. | |
| Has been caused by multi-threading issues on application side. | |
| released | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-06-25 13:23 | thejackimonster | New Issue | |
| 2024-06-25 13:23 | thejackimonster | Additional Information Updated | |
| 2024-07-01 22:23 | thejackimonster | Note Added: 0022781 | |
| 2024-07-04 20:29 | thejackimonster | Note Added: 0022787 | |
| 2024-07-05 00:08 | thejackimonster | Note Added: 0022788 | |
| 2024-07-08 21:33 | thejackimonster | Note Added: 0022799 | |
| 2024-09-23 16:43 | thejackimonster | Assigned To | => thejackimonster |
| 2024-09-23 16:43 | thejackimonster | Status | new => resolved |
| 2024-09-23 16:43 | thejackimonster | Resolution | open => fixed |
| 2024-09-23 16:43 | thejackimonster | Fixed in Version | => 0.22.1 |
| 2024-09-23 16:43 | thejackimonster | Note Added: 0023356 | |
| 2024-10-10 08:20 | schanzen | Note Added: 0023493 | |
| 2024-10-10 08:20 | schanzen | Status | resolved => closed |