4 ms·
The most common situations for having a bug that works on my machine but not other people's have to do with memory access violations. But it seems like when you
by philipov 10y ago
The most common situations for having a bug that works on my machine but not other people's have to do with memory access violations. But it seems like when you containerize the environment, you will change the memory layout and risk the same situation where the bug disappears because you've moved it to a different machine.
- robzyb 10y ago> The most common situations for having a bug that works on my machine but not other people's have to do with memory access violations. That has not been my experience. Especially with software written under time constraints including the constraint of "this is FOSS software that I'm writing in my free time."
- spc476 10y agoThe hardest bug I had to track down exhibited different behavior on different systems. On one system, it only took an hour or two for the program (a daemon) to crash; on another system, several days could pass before a crash. I was able to track it down once I realized that signal handlers were, technically speaking, another thread of execution in a special context ...
- coldtea 10y ago>The most common situations for having a bug that works on my machine but not other people's have to do with memory access violations. Not even close. Different classpaths, different versions of packages, some ENV setting like LOCALE causing havoc, a different configuration between the two installations of the programs that are debugged, a single core vs multi core cpu that masks some race conditions, there are literally MILLIONS of things that can, and in my experience, have, cause something to work in one machine and not another. In fact memory access violations do not even register as a blip on the top-100 reasons...