3 ms·

In this case, reading the linker documentation to find out what the various options do could be more productive than just making random changes to the linker sc

by pja 13y ago

In this case, reading the linker documentation to find out what the various options do could be more productive than just making random changes to the linker script. If you haven't been faced with a mystifying bug where randomly futzing with things in the hope that you would find a change that had a reliable effect was the best hope you had of solving it then you probably haven't been programming long enough.

greenyoda 13y ago
Haven't been programming long enough? If you're the average age on HN, I may have been programming before you were born. :) And I've dealt with lots of mystifying bugs. But my approach to debugging isn't trying random things, it's gathering more information in deliberate ways: reading the code, tracing code with the debugger, adding logging information if the problem doesn't reproduce under the debugger, running test cases that attempt to narrow down the scope of the bug, etc. I've even debugged customer problems that I couldn't reproduce locally by looking at the code and deducing what execution path had to have occurred to account for the reported behavior. That's one situation in which you absolutely can't try random things to see if they work. If I were truly making random changes, it would suggest to me that I had no understanding of how the system worked. If you do understand the system and its potential failure modes, then you can do better than random.
- pja 13y ago
  In this particular case the kernel binary loader was dropping half the binary on the floor, so code would sometimes work and sometimes not in a way which depended on both the environment and the layout of the compiled binary. I'm not surprised the author ended up randomly futzing with things to see if they could find a reliable cause! (This error could have come straight out of the logout; essay that was linked on HN a week or two ago: "I have no tools because I broke my tools with my tools!") Personally I think the reason she was emphasising that changing these things made a difference was because it was so surprising. Now in your infinite and sagacious wisdom you've told us all how she should obviously have been able to debug this problem in a trice using your superior methods. Me, I'm happy to cut her some slack, and recognise that systems development can be a complete nightmare!

by pja 13y ago

greenyoda 13y ago

Haven't been programming long enough? If you're the average age on HN, I may have been programming before you were born. :) And I've dealt with lots of mystifying bugs. But my approach to debugging isn't trying random things, it's gathering more information in deliberate ways: reading the code, tracing code with the debugger, adding logging information if the problem doesn't reproduce under the debugger, running test cases that attempt to narrow down the scope of the bug, etc. I've even debugged customer problems that I couldn't reproduce locally by looking at the code and deducing what execution path had to have occurred to account for the reported behavior. That's one situation in which you absolutely can't try random things to see if they work. If I were truly making random changes, it would suggest to me that I had no understanding of how the system worked. If you do understand the system and its potential failure modes, then you can do better than random.

pja 13y ago
In this particular case the kernel binary loader was dropping half the binary on the floor, so code would sometimes work and sometimes not in a way which depended on both the environment and the layout of the compiled binary. I'm not surprised the author ended up randomly futzing with things to see if they could find a reliable cause! (This error could have come straight out of the logout; essay that was linked on HN a week or two ago: "I have no tools because I broke my tools with my tools!") Personally I think the reason she was emphasising that changing these things made a difference was because it was so surprising. Now in your infinite and sagacious wisdom you've told us all how she should obviously have been able to debug this problem in a trice using your superior methods. Me, I'm happy to cut her some slack, and recognise that systems development can be a complete nightmare!