|| Argh (again)
||Aug. 3rd, 2005 06:49 pm|
this f'ing code has a Heisenbug.|
This is like trying to disect a jellyfish with a spoon. I'm giving up for the day.
Race conditions in multi-threaded systems too, they can be extremely sensitive to timing variations (and debugging output may well cause a context switch). And bugs tied to the message queue in Win32 - sometimes any additional instrumentation ties into the message queue itself and can radically change the symptoms.
Ah yes -- I so rarely work with things where timing is important that I forget that type of particularly nasty bug. Icky.
Debugging Parallel programs? Someone ought to do some research on that, a PHD even...
(Conclusion: Very difficult).
a dangling pointer
You leave his pointer out of this!
Someone get that man a pipe!
Oh my god -- that is horrifying yet brilliant. I am now collapsed with laughter.
Close - it's an object reference issue (as far as I can tell) which is about as close to a pointer as you get in PHP. However it's not a direct memory address in the same way as a pointer, so why it vanishes when I try to examine it, I'm unsure. It's code that works in PHP4 and not PHP5...
I'd be entirely unsurprised by finding an engine bug in PHP4, and 5 is less mature...
It's *probably* part of the deliberate object model changes, but they can be ... "subtle".
Subtle as in "a bug-like feature" or "a feature-like bug?"
Of course, that could be the CTO
I had one a couple of months ago in Perl. I had a variable that wasn't getting its value initialised correctly until I put in a warn statement to check what its value was and then ... it worked. In this case it was definitely a bug in the Perl interpreter, though.