3 ms·

Just a word of caution: I've tried replacing the mitigation patch (which I had been using for 18 months) with the author's minimal fix (the first out of the 6 p

Just a word of caution: I've tried replacing the mitigation patch (which I had been using for 18 months) with the author's minimal fix (the first out of the 6 patches, which is supposed to fix the issue) and I've immediately ran into a deadlock while building Poly/ML 5.9 (3 times, in fact), whereas previously I hadn't encountered this bug before, despite having built Poly/ML many times. This was on a 32-core machine with lots of background compilation going on at the same time (i.e. with a high load). It could be a coincidence or an unrelated bug, but it's also possible that the author's patch might not fix the issue completely.

KyleSanderson 4y ago
Apply the entire series... That's what was likely tested the most.
- FeepingCreature 4y ago
  If the patch that contains the entire fix (minus cleanup) doesn't work, then the entire patchset is unreliable, since the author necessarily doesn't understand it.
  - robocat 4y ago
    You are being wayyyy too harsh - the author is clearly amazingly competent but lacked time to validate the code. This is open source software and if you want your problem diagnosed and fixed then the canonical response is to tell you to stop kvetching and to go ahead and fix it yourself. I couldn’t diagnose or debug some intermittent faults in poor multi-threaded code (written by someone who struggles to think concurrently). I threw the code away and wrote it properly from scratch and that got rid of the data or race conditions causing the intermittent fault. I have had to fix multi-threaded code many many times because I am better than most at properly fixing it.
  - AnssiH 4y ago
    Indeed. But for the record, the author has since found the issue, and in this case it indeed was a bug in the first patch that was inadvertently fixed by a later patch in the series: https://probablydance.com/2022/09/17/finding-the-second-bug-in-glibcs-condition-variable/#comment-15150 https://probablydance.com/2022/09/17/finding-the-second-bug-...

KyleSanderson 4y ago

Apply the entire series... That's what was likely tested the most.

FeepingCreature 4y ago
If the patch that contains the entire fix (minus cleanup) doesn't work, then the entire patchset is unreliable, since the author necessarily doesn't understand it.
- robocat 4y ago
  You are being wayyyy too harsh - the author is clearly amazingly competent but lacked time to validate the code. This is open source software and if you want your problem diagnosed and fixed then the canonical response is to tell you to stop kvetching and to go ahead and fix it yourself. I couldn’t diagnose or debug some intermittent faults in poor multi-threaded code (written by someone who struggles to think concurrently). I threw the code away and wrote it properly from scratch and that got rid of the data or race conditions causing the intermittent fault. I have had to fix multi-threaded code many many times because I am better than most at properly fixing it.
- AnssiH 4y ago
  Indeed. But for the record, the author has since found the issue, and in this case it indeed was a bug in the first patch that was inadvertently fixed by a later patch in the series: https://probablydance.com/2022/09/17/finding-the-second-bug-in-glibcs-condition-variable/#comment-15150 https://probablydance.com/2022/09/17/finding-the-second-bug-...