if ( $debugging ) { work_right() } else { fail_miserably() }

chaoticset on 2004-02-23T15:22:35

Still having trouble getting Net::AIM working. At this point I've stripped out niceties, compared to examples, etc., and can find no significant difference.

(I know, 'significant' in my mind is clearly not quite matching up with 'significant' in terms of actual characters in the code.)

I drag out the debugger section of the Camel and start sticking breakpoints, like voodoo pins, into some of the problem areas. Stepping through the debugger...

...everything works.

I figure I've just missed that it works, and rerun it sans -d. Still doesn't work.

Maybe I'm going insane. I need more coffee. Once that is fetched and I call my father, I'll slap my eyeballs against this thing again and see what falls out.


Congratulations!

wnodom on 2004-02-23T16:10:00

You have a heisenbug!

Re:Congratulations!

chaoticset on 2004-02-23T16:44:10

Strangely, it turns out there's not really a bug per se, just unexpected behavior. See next entry.

Async Call?

brianiac on 2004-02-23T16:25:05

When this happened to me while working on a network-related task, I found that the time taken in stepping through the code was either allowing an unexpectedly ansyncronous call to complete, or allowing a remote resource to complete (unintentionally asyncronous).

each

Ovid on 2004-02-23T16:49:08

I've had this problem before. In my case, I didn't appear to be iterating over a hash properly. However, when I stuck in debugging code to dump the hash, it worked fine. When I dropped to the debugger and manually inspected the hash, it still worked. As it turns out, the problem was because I was calling each on the hash and dying if I had problems. However, I was catching the die in an eval and reentered the subroutine with correct arguments (this was in a test, so you can see why). When I reentered, each was not reset, thus causing the failure.