5 ms·

This seems like some really good debugging effort, kudos. But, my takeaway from this is that there’s a glibc bug which causes deadlocks in correct code, and a

by mort96 4y ago

This seems like some really good debugging effort, kudos. But, my takeaway from this is that there’s a glibc bug which causes deadlocks in correct code, and a proposed fix (even if partial) has been available for years, and glibc still hasn’t shipped a version with the fix so it’s up to distros and users to patch the broken glibc code. Reminds me of how a glibc update broke GNU m4 and GNU didn’t ship a fix to m4 for years, so it was up to distros and users to patch the latest release of GNU m4 to make it compile with the latest version of GNU glibc. And then a couple of years later GNU shipped another version of glibc which broke m4. GNU doesn’t strike me as an organisation which places a lot of value on software quality and reliability.

rekado 4y ago
> GNU doesn’t strike me as an organisation which places a lot of value on software quality and reliability. This stems from a misunderstanding of what GNU is. Ideally all projects under the GNU umbrella would work towards a unified operating system, but that's sadly not what it's like. The GNU project is not much of a project in the common sense of the word, nor is it much of an organisation. This is one of the many reasons why https://gnu.tools https://gnu.tools exists, a subset of GNU with common goals and values, including collaborative project management.
- xwolfi 4y ago
  It sounds silly for deep theoricians and a somewhat politically active organization like GNU to have wanted to go all the way to an OS, the kind of software where you really need to throw all the beauty out of the window and solve dumb users tangible problems, like how to read a bluray from an obscure proprietary drive or how to run a game with a monopolistic corporation's binary drivers. GNU can never succeed at it because it can never compromise and maybe that's fine. It's a shame that it s considered a failure when they accomplished so much in the OS scaffolding part.
- mort96 4y ago
  I kind of get that. And if a change in GNU glibc caused a bug in GNU wget, I would hope that wget would release a fix relatively quickly, but I wouldn't necessarily have any special expectations just because glibc and wget are both part of GNU. But I wish that the projects in the GNU toolchain would at the very least collaborate. The combination of glibc + gcc + autotools + m4 makes such a core part of any GNU system that you'd hope that GNU cares to keep them mutually compatible. So when they release an update to glibc which breaks m4 which makes it impossible to compile the current version of the GNU toolchain using the current version of the GNU toolchain, that's extremely disappointing.
  - yjftsjthsd-h 4y ago
    It does naively seem like a central library like glibc would want to run regression integration tests on every new version to make sure they're not breaking the utterly massive ocean of software that depends on them, and that the very obvious first step in that direction would be to run tests using software from the same group and/or core libraries/software that they know are required for a lot of base systems to work (ex. GNU coreutils, GCC, clang, busybox). I suspect it does in fact mostly boil down to resourcing problems - although that just begs further questions, since I would expect that organizations like Google or Red Hat would consider that kind of thing important enough to support.
    - dezgeg 4y ago
      Using GNU Guix (the distribution) should be a logical and simple test-bed to see how exactly glibc/gcc pre-release would affect downstream packages.
stefan_ 4y ago
It's hilarious how many of these stories there are. I remember debugging a DNS issue on an embedded system; the resolv.conf changed but the program continued trying the old DNS server. Turns out GLIBC will read the resolv.conf once on startup and never again after (unless specifically invalidated). Except most people will never notice this behavior because (1) most distributions carry a patch from 2004 that reloads it transparently or (2) use libraries that just always invalidate it, just to be sure. This stupidity surfaces everywhere; here is a Go bug report for it: https://github.com/golang/go/issues/21083 https://github.com/golang/go/issues/21083
- ChickeNES 4y ago
  > This stupidity surfaces everywhere; here is a Go bug report for it: > https://github.com/golang/go/issues/21083 https://github.com/golang/go/issues/21083 The irony that they proposed a fix in 2017 but never got around to actually implementing it...
- yencabulator 4y ago
  Similar issue for not noticing changes in /etc/localtime: https://github.com/golang/go/issues/28020 https://github.com/golang/go/issues/28020
deleted 4y ago
[deleted]
userbinator 4y ago
GNU doesn’t strike me as an organisation which places a lot of value on software quality and reliability. That's not surprising, because their main purpose is to promote the GPL and "free as in freedom" software. I've heard theories that their software is deliberately overly complex and uniquely different from other implementations in order to make it easier to find GPL violations. In other words, they're optimising for something other than quality. I've inspected the glibc condition variable implementatoin (while looking at what may be a slightly different bug, or it could be another manifestation of this one; not sure at this point since it was years ago) and the first thing I noticed was that it is disturbingly complex.
- pengaru 4y ago
  > That's not surprising, because their main purpose is to promote the GPL and "free as in freedom" software. You're conflating the FSF and the GNU project.
  - userbinator 4y ago
    Same difference; this is in contrast to e.g. BSD, which is far less politically motivated. (And AFAIK they have no problems in their CV implementation that I know of...)

by mort96 4y ago

rekado 4y ago

> GNU doesn’t strike me as an organisation which places a lot of value on software quality and reliability. This stems from a misunderstanding of what GNU is. Ideally all projects under the GNU umbrella would work towards a unified operating system, but that's sadly not what it's like. The GNU project is not much of a project in the common sense of the word, nor is it much of an organisation. This is one of the many reasons why https://gnu.tools https://gnu.tools exists, a subset of GNU with common goals and values, including collaborative project management.

xwolfi 4y ago
It sounds silly for deep theoricians and a somewhat politically active organization like GNU to have wanted to go all the way to an OS, the kind of software where you really need to throw all the beauty out of the window and solve dumb users tangible problems, like how to read a bluray from an obscure proprietary drive or how to run a game with a monopolistic corporation's binary drivers. GNU can never succeed at it because it can never compromise and maybe that's fine. It's a shame that it s considered a failure when they accomplished so much in the OS scaffolding part.
mort96 4y ago
I kind of get that. And if a change in GNU glibc caused a bug in GNU wget, I would hope that wget would release a fix relatively quickly, but I wouldn't necessarily have any special expectations just because glibc and wget are both part of GNU. But I wish that the projects in the GNU toolchain would at the very least collaborate. The combination of glibc + gcc + autotools + m4 makes such a core part of any GNU system that you'd hope that GNU cares to keep them mutually compatible. So when they release an update to glibc which breaks m4 which makes it impossible to compile the current version of the GNU toolchain using the current version of the GNU toolchain, that's extremely disappointing.
- yjftsjthsd-h 4y ago
  It does naively seem like a central library like glibc would want to run regression integration tests on every new version to make sure they're not breaking the utterly massive ocean of software that depends on them, and that the very obvious first step in that direction would be to run tests using software from the same group and/or core libraries/software that they know are required for a lot of base systems to work (ex. GNU coreutils, GCC, clang, busybox). I suspect it does in fact mostly boil down to resourcing problems - although that just begs further questions, since I would expect that organizations like Google or Red Hat would consider that kind of thing important enough to support.
  - dezgeg 4y ago
    Using GNU Guix (the distribution) should be a logical and simple test-bed to see how exactly glibc/gcc pre-release would affect downstream packages.

stefan_ 4y ago

It's hilarious how many of these stories there are. I remember debugging a DNS issue on an embedded system; the resolv.conf changed but the program continued trying the old DNS server. Turns out GLIBC will read the resolv.conf once on startup and never again after (unless specifically invalidated). Except most people will never notice this behavior because (1) most distributions carry a patch from 2004 that reloads it transparently or (2) use libraries that just always invalidate it, just to be sure. This stupidity surfaces everywhere; here is a Go bug report for it: https://github.com/golang/go/issues/21083 https://github.com/golang/go/issues/21083

ChickeNES 4y ago
> This stupidity surfaces everywhere; here is a Go bug report for it: > https://github.com/golang/go/issues/21083 https://github.com/golang/go/issues/21083 The irony that they proposed a fix in 2017 but never got around to actually implementing it...
yencabulator 4y ago
Similar issue for not noticing changes in /etc/localtime: https://github.com/golang/go/issues/28020 https://github.com/golang/go/issues/28020

deleted 4y ago

[deleted]

userbinator 4y ago

GNU doesn’t strike me as an organisation which places a lot of value on software quality and reliability. That's not surprising, because their main purpose is to promote the GPL and "free as in freedom" software. I've heard theories that their software is deliberately overly complex and uniquely different from other implementations in order to make it easier to find GPL violations. In other words, they're optimising for something other than quality. I've inspected the glibc condition variable implementatoin (while looking at what may be a slightly different bug, or it could be another manifestation of this one; not sure at this point since it was years ago) and the first thing I noticed was that it is disturbingly complex.

pengaru 4y ago
> That's not surprising, because their main purpose is to promote the GPL and "free as in freedom" software. You're conflating the FSF and the GNU project.
- userbinator 4y ago
  Same difference; this is in contrast to e.g. BSD, which is far less politically motivated. (And AFAIK they have no problems in their CV implementation that I know of...)