4 ms·

by go away, you of course mean hidden to be found and solved later? bugs do not typically just fix themselves.

by foxhill 13y ago

dalke 13y ago
Can't say anything about that project, but there could be a build dependency error where a change didn't get propagated all the way through. The "bug" isn't so much a coding bug but a synchronization bug that can be fixed by doing a full rebuild. For example, on one system I used there was a ~2 second difference between my desktop machine, the build machine, and the NFS host for directory I was working in. This would sometimes lead to: make: warning: Clock skew detected. Your build may be incomplete. If I did a save to a .C file just after the .o file was written, then it might still have a timestamp which was older than the .o, so not included in a rebuild. This required occasional manual deletes of the .o file to make sure that it was building correctly, and we probably did a full rebuild of the entire code every once in a while to reduce these sorts of problems. (This was back in the c-front days, with 15 minute compilation times.)
dthunt 13y ago
Not necessarily. A decent percentage of the time someone is experiencing a "heisenbug" it's because there are some stale object files sitting around, and the build state has gotten inconsistent (makefile bugs, bad tracking of dependencies, or what have you). You go to build debug, everything works, you shrug, make clean, remake, and then you're golden again. Obviously that's really not the way to go, though, because you risk mistaking an uncommon crash for "just had to rebuild, I guess" - but if you're comfortable reading assembly or what-have-you, you can usually confirm the "stale object files" thing easily - and then fix your build ;)
walshemj 13y ago
Ironically no as dalke comments below I think it mist have been some odd build efect over several hundred modules of code.

by go away, you of course mean hidden to be found and solved later? bugs do not typically just fix themselves.

by foxhill 13y ago

by go away, you of course mean hidden to be found and solved later? bugs do not typically just fix themselves.

dalke 13y ago

Can't say anything about that project, but there could be a build dependency error where a change didn't get propagated all the way through. The "bug" isn't so much a coding bug but a synchronization bug that can be fixed by doing a full rebuild. For example, on one system I used there was a ~2 second difference between my desktop machine, the build machine, and the NFS host for directory I was working in. This would sometimes lead to: make: warning: Clock skew detected. Your build may be incomplete. If I did a save to a .C file just after the .o file was written, then it might still have a timestamp which was older than the .o, so not included in a rebuild. This required occasional manual deletes of the .o file to make sure that it was building correctly, and we probably did a full rebuild of the entire code every once in a while to reduce these sorts of problems. (This was back in the c-front days, with 15 minute compilation times.)

dthunt 13y ago

Not necessarily. A decent percentage of the time someone is experiencing a "heisenbug" it's because there are some stale object files sitting around, and the build state has gotten inconsistent (makefile bugs, bad tracking of dependencies, or what have you). You go to build debug, everything works, you shrug, make clean, remake, and then you're golden again. Obviously that's really not the way to go, though, because you risk mistaking an uncommon crash for "just had to rebuild, I guess" - but if you're comfortable reading assembly or what-have-you, you can usually confirm the "stale object files" thing easily - and then fix your build ;)

walshemj 13y ago

Ironically no as dalke comments below I think it mist have been some odd build efect over several hundred modules of code.