10 ms·

Way before QNX went shared/open source, they were as they are now. But they had just released Neutrino a major update which basically took their QNX4 microkerne

by fargle 5y ago

Way before QNX went shared/open source, they were as they are now. But they had just released Neutrino a major update which basically took their QNX4 microkernel and mated it with a POSIX/GNU/UNIX-like userland. And it was for a while, free as in beer, for R&D type use. So that all sounded great and we tried it, this was around 20 years ago. It was a disaster. The same kind of shoddy work, race-condition, type bugs all over the place. - malloc broken under heavy multi-threaded load. Replaced with dl-malloc. - serial driver (16550) broke under heavy load. Wrote our own replacement. - ethernet driver broke under heavy load. Had to replace intel cards with 3-com (or vice-versa) to use a different driver. - had to write/rewrite several other drivers. Interestingly the only think I liked about QNX is that user mode drivers are very nice and easy to write. - compiler, QNX bespoke port of GCC, crashed and broke on large codebases (could be because of malloc). Had to re-port GCC (which was easy) and build our own toolchains. When we got done trying it our adamant report was GARBAGE NEVER USE. Got overrode by management. because we succeeded in making it work. Sigh. Started using it for products, so we bought commercial not-free license AND support. Reported all of the above bugs and 20 more, with reproducible test cases. QNX "promised to fix them in the next release". This was 20 years ago. Finally after many years we completed excising QNX from our products. We never had a problem with ps, but it was probably broken. This company was producing garbage in the late nineties and didn't care. They produce garbage now. They didn't have enough or experienced enough developers to be trying to pull together a whole OS, so it was about how you'd expect a university or hobby project. The only place this author got it wrong is that on QNX, if you assume the OS or compiler is at fault, you are probably right.

fwip 5y ago
QNX is the only compiler I've ever used that removing a comment broke my code at runtime. If I remember right, the comment was: // printf("debug 2"); I added in an additional comment directly above that one. // load-bearing comment, do not remove
- bradrn 5y ago
  …how‽ What is the explanation for this?
  - mst 5y ago
    No idea, but I do know there was a gcc port to NCR UNIX bootstrapping off their own compiler that stalled for a while until one of the developers worked out that it unrolled switch statements to if+goto ... and used the label 'dflt:' for the default case of the switch. Sucked to be you if you decided to name one of your own labels that.
  - fwip 5y ago
    Honestly, I'm not sure. In hindsight, I think that there must have been a race condition somewhere else in my code (school project) that this was somehow exposing. Removing the comment reliably resulted in an executable that always did the wrong behavior, and leaving the comment in, the program always worked.
    - zoomablemind 5y ago
      printf() is an old-school fuzzer, so to speak. It may be just a line, but underneath, the call to it brings in a ton of branching and memory alloc and access. So quite often any latent memory leaks or code issues could lead to such odd behavior. Sometimes it's the opposite - "works" with printf(), but segfaults in some odd place or infiniloops without it. At times like this, -Wall, valgrind, and critical thinking are the ways to "cherchez le 'bug'"... Multithreaded it is? Good luck!
      - Arnavion 5y ago
        The line in question is a comment, not a call to printf.
        dotancohen 5y ago
        You don't know what the compiler is doing behind the scenes before it figures out that is a comment. For instance, it might parse the entire function body for printf() and if it finds it then loads some library, only then getting around to actually parsing the function line by line. Think of Javascript hoisting - only dumber.
- dotancohen 5y ago
  > // load-bearing comment, do not remove I've actually seen a "load bearing comment" with reflection in a PHP app that I had inherited. And some Python packages uses them for defining tests. But I love the term "load bearing comment". I'm definitely adding this to my vocabulary.
- bostik 5y ago
  Fortran compiler (f77 maybe?) on a Sun system had reserved filenames. In Finland, back in the late 90's first-year chemistry students were still exposed to Fortran as their entry to programming. I was helping another student debug their programming assignment, which blew up the compiler. Over the shoulder I couldn't figure out what it supposedly wrong, so we copied it (via /scratch) to my home directory. I just shortened the name a bit. Tried to compile on my account, it worked. No errors. Confirmed it was the same compiler being invoked. So we copied the file to a new name on the other student's account and tried. Worked. Same file content, two different file names. One compiles fine, another hits internal compiler error paths. Introduction to programming indeed.

by fargle 5y ago

fwip 5y ago

QNX is the only compiler I've ever used that removing a comment broke my code at runtime. If I remember right, the comment was: // printf("debug 2"); I added in an additional comment directly above that one. // load-bearing comment, do not remove

bradrn 5y ago
…how‽ What is the explanation for this?
- mst 5y ago
  No idea, but I do know there was a gcc port to NCR UNIX bootstrapping off their own compiler that stalled for a while until one of the developers worked out that it unrolled switch statements to if+goto ... and used the label 'dflt:' for the default case of the switch. Sucked to be you if you decided to name one of your own labels that.
- fwip 5y ago
  Honestly, I'm not sure. In hindsight, I think that there must have been a race condition somewhere else in my code (school project) that this was somehow exposing. Removing the comment reliably resulted in an executable that always did the wrong behavior, and leaving the comment in, the program always worked.
  - zoomablemind 5y ago
    printf() is an old-school fuzzer, so to speak. It may be just a line, but underneath, the call to it brings in a ton of branching and memory alloc and access. So quite often any latent memory leaks or code issues could lead to such odd behavior. Sometimes it's the opposite - "works" with printf(), but segfaults in some odd place or infiniloops without it. At times like this, -Wall, valgrind, and critical thinking are the ways to "cherchez le 'bug'"... Multithreaded it is? Good luck!
    - Arnavion 5y ago
      The line in question is a comment, not a call to printf.
      - dotancohen 5y ago
        You don't know what the compiler is doing behind the scenes before it figures out that is a comment. For instance, it might parse the entire function body for printf() and if it finds it then loads some library, only then getting around to actually parsing the function line by line. Think of Javascript hoisting - only dumber.
dotancohen 5y ago
> // load-bearing comment, do not remove I've actually seen a "load bearing comment" with reflection in a PHP app that I had inherited. And some Python packages uses them for defining tests. But I love the term "load bearing comment". I'm definitely adding this to my vocabulary.
bostik 5y ago
Fortran compiler (f77 maybe?) on a Sun system had reserved filenames. In Finland, back in the late 90's first-year chemistry students were still exposed to Fortran as their entry to programming. I was helping another student debug their programming assignment, which blew up the compiler. Over the shoulder I couldn't figure out what it supposedly wrong, so we copied it (via /scratch) to my home directory. I just shortened the name a bit. Tried to compile on my account, it worked. No errors. Confirmed it was the same compiler being invoked. So we copied the file to a new name on the other student's account and tried. Worked. Same file content, two different file names. One compiles fine, another hits internal compiler error paths. Introduction to programming indeed.