Hello -<p>[ I'm interested in general advice here, yet wish to give an example to set it up. ]<p>You have a complex software package that runs on Linux, macOS and Windows. Let's say it also interfaces with a complex piece of hardware via PCIe.<p>When you test the software on Linux, you get output about, say, an I/O page fault. There are some details, but you're not an experienced kernel hacker, so progress is slow if you try to dig in on it.<p>Some of your colleagues suggest that you stay focused on debugging the problem on Linux. Others suggest running the same test case on macOS and Windows, to see what happens, and if that sheds any light on the problem.<p>I'm interested in your thoughts on which approach you would take, with whatever qualifiers you wish to add, and why.<p>The more general question here is when you have a bug roughly like the one described above, is your preference to stay with one particular set-up and dig for all the details you can (call this "depth-first" debugging, maybe) or do you prefer to go breadth-first (when you can) to try to narrow things down?
While I do have some experience with kernel code, if there isn't something jumping right at me after some hour of staring at code and maybe inserting some debug statements on a hunch, I might try the other OSes just as a sort of sanity check to see if the issue even exists at all, or if everything works flawlessly. Or maybe it will break in another way and I'll suddenly have a lightbulb moment that helps me identifying the problem better. Could it be a hardware issue? Could it be that just my device is faulty? Just some revisions of it?<p>Generally I switch between approaches as I see fit, on a hunch you could say. There's no point in banging your head against a wall in some dead end for two hours.
> Some of your colleagues suggest that you stay focused on debugging the problem on Linux. Others suggest running the same test case on macOS and Windows, to see what happens, and if that sheds any light on the problem.<p>The latter option seems clearly better to me but I don't know if that makes for general advice. It's also easy to pick that option when the alternative isn't specified at all (we don't know what "keep debugging on Linux" means).
It depends.<p>Do I have a red-hot "it's probably this" idea that I have some confidence in? If so, I probably chase that one in depth first, at least to the point of being able to confirm or disprove.<p>In the exact scenario you gave, I'd probably do breadth-first, because I don't know if it's OS-specific or not, and the possible causes are different depending on whether it's Linux-only or not.