4 ms·

> Typically you have at least two build modes, debug and release. Legacy cargo-cult holdover from the 1980's. No real reason for it today. > also a program wi

> Typically you have at least two build modes, debug and release. Legacy cargo-cult holdover from the 1980's. No real reason for it today. > also a program without optimizations behaves the same as with optimizations Not when you want to debug it.

jstimpfle 3y ago
That's a really interesting mix of wild claims and plain wrong statements.
CyberDildonics 3y ago
I'm not sure where you got these ideas, but there are tons of benefits to debug builds like catching out of bounds lookups on vectors the moment they happen and faster compilation. It's bizarre that you don't realize everyone works this way. Not when you want to debug it. I think you're mistaking debug information not lining up with your program for different behavior, but these are not the same thing.
- mgaunard 3y ago
  Debug/sanitized builds are for unit tests. Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario.
  - CyberDildonics 3y ago
    Debug/sanitized builds are for unit tests. What about just compiling and running your program after you make a change or get a crash? Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario. Right... What's your point? This scenario doesn't overlap with regular iterations. Normal workflow and a crash after a program is distributed are two separate things.
    - mgaunard 3y ago
      The crash when your program is distributed is the normal workflow. What matters is that your program runs flawlessly in its distributed environment, not that your test suite passes locally. Testing is but a proxy to achieve the true goal, and is far from perfect.
      - CyberDildonics 3y ago
        Your normal workflow is only finding bugs once you've released your program to other people? You don't find any bugs while you work on it? You write a program and if it compiles you immediately assume everything is fine, release it and wait for someone to complain? Do you realize that this thread was about someone saying that debug builds are a legacy holdover from the 80s ? Testing is but a proxy to achieve the true goal, and is far from perfect. What is this supposed to mean?
        mgaunard 3y ago
        The bugs you find while working on something are trivial ones; the hard bugs come from integration with other components. Additionally most software runs as a service this day, so you have fast deployment iterations to collect errors. Even for something like games, they get OTA updates all the time, fixing bugs that were only found while people were playing the game. > What is this supposed to mean? This is a pretty simple sentence in straightforward English. Which word do you have a problem with?
        CyberDildonics 3y ago
        What is it exactly that you think you're replying to? All this was about was someone thinking there was no use for debug builds. You're hallucinating some sort of discussion or argument about distributed software, services, updates, none of it is even coherent to what is being talked about.
        mgaunard 3y ago
  - flohofwoe 3y ago
    Postmortem debugging on production builds and without debug info is just harder (depends on how much postmortem info your bug report system provides, and at least on Windows it still makes sense to create a PDB file and archive that inhouse to associate that with the minidump you're getting from the bug report, slightly mismatched debug info is still much better than no debug info at all). A production build crash doesn't mean that the symptoms are not reproducible on a debug build, and investigating the debug build after the bug has been reproduced is a lot more convenient. Also a lot more bugs show up and are already fixed during development and never even make it to CI or even out into the wild. That's were debug builds and debuggers are most useful (during the initial development phase). Sometimes I really have a feeling that software development is moving backward in time (shakes head). Debuggers are incredibly poweful tools, use them!
    - mgaunard 3y ago
      Of course you use the debugger to debug the core. Doesn't change the fact it's completely unrealistic to expect that you can do that with a full debug build. The industry has moved towards software as a service, and sometimes your service crashes and you need to figure out why. Even if you want to turn the problem into a regression test that you can run a debug build against, you'll still need to look at the core of the optimized build to figure out what happened to begin with.

jstimpfle 3y ago

That's a really interesting mix of wild claims and plain wrong statements.

CyberDildonics 3y ago

I'm not sure where you got these ideas, but there are tons of benefits to debug builds like catching out of bounds lookups on vectors the moment they happen and faster compilation. It's bizarre that you don't realize everyone works this way. Not when you want to debug it. I think you're mistaking debug information not lining up with your program for different behavior, but these are not the same thing.

mgaunard 3y ago
Debug/sanitized builds are for unit tests. Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario.
- CyberDildonics 3y ago
  Debug/sanitized builds are for unit tests. What about just compiling and running your program after you make a change or get a crash? Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario. Right... What's your point? This scenario doesn't overlap with regular iterations. Normal workflow and a crash after a program is distributed are two separate things.
  - mgaunard 3y ago
    The crash when your program is distributed is the normal workflow. What matters is that your program runs flawlessly in its distributed environment, not that your test suite passes locally. Testing is but a proxy to achieve the true goal, and is far from perfect.
    - CyberDildonics 3y ago
      Your normal workflow is only finding bugs once you've released your program to other people? You don't find any bugs while you work on it? You write a program and if it compiles you immediately assume everything is fine, release it and wait for someone to complain? Do you realize that this thread was about someone saying that debug builds are a legacy holdover from the 80s ? Testing is but a proxy to achieve the true goal, and is far from perfect. What is this supposed to mean?
      - mgaunard 3y ago
        The bugs you find while working on something are trivial ones; the hard bugs come from integration with other components. Additionally most software runs as a service this day, so you have fast deployment iterations to collect errors. Even for something like games, they get OTA updates all the time, fixing bugs that were only found while people were playing the game. > What is this supposed to mean? This is a pretty simple sentence in straightforward English. Which word do you have a problem with?
        CyberDildonics 3y ago
        What is it exactly that you think you're replying to? All this was about was someone thinking there was no use for debug builds. You're hallucinating some sort of discussion or argument about distributed software, services, updates, none of it is even coherent to what is being talked about.
        mgaunard 3y ago
- flohofwoe 3y ago
  Postmortem debugging on production builds and without debug info is just harder (depends on how much postmortem info your bug report system provides, and at least on Windows it still makes sense to create a PDB file and archive that inhouse to associate that with the minidump you're getting from the bug report, slightly mismatched debug info is still much better than no debug info at all). A production build crash doesn't mean that the symptoms are not reproducible on a debug build, and investigating the debug build after the bug has been reproduced is a lot more convenient. Also a lot more bugs show up and are already fixed during development and never even make it to CI or even out into the wild. That's were debug builds and debuggers are most useful (during the initial development phase). Sometimes I really have a feeling that software development is moving backward in time (shakes head). Debuggers are incredibly poweful tools, use them!
  - mgaunard 3y ago
    Of course you use the debugger to debug the core. Doesn't change the fact it's completely unrealistic to expect that you can do that with a full debug build. The industry has moved towards software as a service, and sometimes your service crashes and you need to figure out why. Even if you want to turn the problem into a regression test that you can run a debug build against, you'll still need to look at the core of the optimized build to figure out what happened to begin with.