Huge Reset On Debian Release-Critical Bug-Tracking

“2619 release-critical bugs were closed and NONE were opened.”
 
See Release-critical bugs status, Mon Nov 14 12:00:00 UTC 2016
Not sure what happened here. Debian’s release-critical bug count has been high for months with many failures to build from source after changes to GCC and several libraries.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , , , . Bookmark the permalink.

11 Responses to Huge Reset On Debian Release-Critical Bug-Tracking

  1. oiaohm says:

    By users of non-FLOSS C/C++ compilers, Fifi? I imagine not.
    DrLoser it documented in MSVC documentation let alone most other compliers because users hit it all the time.
    http://siomsystems.com/mixing-visual-studio-versions/
    This is something kind of important. You want to drive you project up the wall. Run multi versions of incompatible libraries this include parts build with different versions of visual studio.

    So yes the bug snowball problem does exist on Windows for Windows developers. You want well behaving programs made by visual studio or gcc or any complier all the parts the program will be using will be made using the same tree of libraries to have the least issues. You really don’t want more than 1 version of C at play if you can avoid it.

    Those are not seeing the snowball normal are either working on small programs or not fully rebuilding their programs and having users put up with random crashes due to library conflicts.

    So when ever a c/c++ project open source or closed source changes compliers stuff not building is status normal. When the project is the size of debian its a few 1000+ parts failing.

    In fact the incompatible between complier versions is both ways. MSVC will refuse to build older code than itself at times when it is without question wrong and MSVC older complier will fail to build MSVC newer complier code because feature is missing. You can take MSVC out of that line and use name of any C/C++ complier.

    Is this that gcc is that bad no. Gcc is about average at failing. If you are not seeing failure due to complier change either you are really lucky and your code base is clean or you failed to rebuild a part that ends up coming back and failing on the end user.

    Debian policy is simple when changing compliers rebuild everything and set off as many of the hidden flaws as possible. This is very good policy to follow no matter the platform you are developing for.

    Windows, Linux, OS X…. C/C++ compliers does not matter who makes them the C and C++ standard is always being added to this always brings incompatibles.

  2. dougman says:

    Ignorant useless moron, did you file your deformation grievances yet?

    To get things started, here is a wikihow: http://www.wikihow.com/Sue-for-Defamation

    Also, I would take a good look at #3.

  3. DrLoser says:

    Let me state this plainly, oiaohm. On behalf, I think, of all of us here (and this includes those who disagree on other more fundamental things).

    You are an ignorant useless moron. I think we can all agree on this.

    Shut up.

  4. DrLoser says:

    Remember when you see a complier triggered snow ball the bugs at the core of the snowball were already present just were not being detected and most of the bugs about x and y application that will not build because z are missing are fixed as soon as all the z at the centre of the snowball are fixed. This is why it goes up fast and fall fast and stalls in the middle…

    Yes, indeed, I remember … hey, wait a moment. Wall’O’Gibberish Special Microwave Memories!

    I regret to admit this, Fifi, but Douglas is 100% correct. You are a total prat.

    Why Robert bothers to pay attention to your babbling is entirely beyond the rest of us.

  5. DrLoser says:

    The effect has been documented for a very long time.

    By users of non-FLOSS C/C++ compilers, Fifi? I imagine not.

    You can “of course” prove me wrong with cites.

  6. Wizard Emeritus says:

    “Deaf Spy its not poor C and C++ complier as such is a poor C and C++ standards allowing … ”
    yadda, yadda, yadda..
    More excuse making, as if that changes the facts as noted.

    It doesn’t.

  7. oiaohm says:

    Deaf Spy its not poor C and C++ complier as such is a poor C and C++ standards allowing bad things and when compliers get updated to detect them all hell break loss. This is not a debian or Linux or gcc only thing. The effect has been documented for a very long time.

    https://wiki.debian.org/GCC6 these pages never end up exactly updated. The big spike is when GCC 6 is set default for building everything with debian that Robert sees.

    https://gcc.gnu.org/gcc-6/changes.html
    Type-based alias analysis now disambiguates accesses to different pointers. This improves precision of the alias oracle by about 20-30% on higher-level C++ programs. Programs doing invalid type punning of pointer types may now need -fno-strict-aliasing to work correctly.
    Yes this is complier now detecting something that C++ programs could have been doing under gcc before 6 and still be doing under MSVC that is technically breach of C++ standard for over 20 years. Method to-do this checking was only invented start last year before that it was up to the coders to be skilled enough not to make these mistakes.

    Fairly much every new complier adding some feature to check for faults that have not been ever complier audited for before equals bug spike.

    This time it was not C code going sky high but mostly bad C++ code. Also gcc altered it default C++ standard level up to gnu++14(that is C++14 complete plus gnu extensions)

    Also the bug spike does not require that many bugs. The complier refuses to build a set of key libraries with the defected fault then all the applications that depend on those libraries throw bugs as well because they are refusing to build. Yes this is the magic complier triggered snowball.

    Why is it the complier triggered snowball is if you go to freebsd that builds with clang/llvm instead of gcc they have the same effect when a new complier with a new audit source feature appears. Also the complier triggered snowball was written about by closed source unix developers so its a really odd problem.

    Remember when you see a complier triggered snow ball the bugs at the core of the snowball were already present just were not being detected and most of the bugs about x and y application that will not build because z are missing are fixed as soon as all the z at the centre of the snowball are fixed. This is why it goes up fast and fall fast and stalls in the middle.

    Deafspy something to remember many things gcc pulled out that is flawed code Microsoft C++ compliers for drivers and applications gives no error message even that at runtime it truly wrong. Also Microsoft Visual Studio is not up to C++14 like Clang 3.4+ and gcc 6+ is. So Microsoft compliers are crappy they let way more side.

    The final thing to remember Deafspy if you accessed every research project for every diagnostic method to find known C++/C code failures to follow standard other than human reading the code you still would be missing about 40% of cases as there is no invented method to diagnose those. So the best C/C++ complier on earth is horribly flawed. Hopefully one day that figure will be less than 10 percent. Its why project/program that get a clean bill of health from coverity static analysis 12 months go can have many thousand of bugs now and it all due to improving static analysis methods for finding coder errors. So complier triggered snowball bug should be expected to happen for many more years because C/C++ compliers are no were closed to detect all the possible faults they can yet.

  8. Deaf Spy says:

    This is yet another reason I hate C

    Why hating C, when the culprit (according to Fifi) is that crappy compiler gcc?

  9. oiaohm wrote, ” Gcc gets released with some new feature that makes it picking on old flawed code debian critical bug count goes though the roof and 6 months latter it falls back down.”

    This is yet another reason I hate C.

  10. oiaohm says:

    Robert this is a repeating pattern. Gcc gets released with some new feature that makes it picking on old flawed code debian critical bug count goes though the roof and 6 months latter it falls back down.

    You can see 07 2013 to 2014 another major gcc change on that graph causing small but same shockwave effect due to gcc change. The current change was a little broader effecting.

    Its about every 2 years it happens.

  11. DrLoser says:

    I presume you have offered your services in support, Robert.

Leave a Reply

Your email address will not be published. Required fields are marked *