Monday, October 6, 2014
Heisenbug
One of the more interesting bugs I've solved disappeared when I tried fixing it.
Update: The linked page no longer works. Here's what I wrote:
The most interesting bug I’ve solved disappeared when I tried debugging it.
I was comparing a sub-class of java.util.Date with a java.util.Date object using date.after(subInstance). However, no matter what dates I used, the Date always seemed to be after() the sub-class date.
So I naturally attached the debugger and after a bit of work identifying the correct line, I inserted a breakpoint. When the breakpoint tripped, I checked the variables list and everything looked appropriate, so I clicked run. And of course, the comparison now worked correctly. Scratching my head, I tried it a few more times and the comparison still worked.
Confused, thinking maybe I had inadvertently been using bad data earlier, I turned off the debugger and went back to work.
But the next time I tried it, it was still not working. So I turned the debugger on and set the breakpoint again and the comparison started worked again. I tested this multiple times and became convinced that running the debugger was fixing the bug!
The breakthrough came when I turned on the debugger and moved the breakpoint to a different line. This time the bug was still there!
Turns out the implementer of the subclass was concerned about performance when dealing with large numbers of date objects that would get deserialized from the database. So they wrote a lazy implementation of the Date class that delayed initializing many fields of the object until any method was called on the instance of the Date subclass.
When I used date.after(subInstance), no methods were called on subInstance. Its uninitialized fields were accessed directly, so it started at time 0.
When the breakpoint tripped, it would call toString() on the subInstance to display its value in the variable list, triggering the lazy initialization of the object and making the bug disappear.
Update: The linked page no longer works. Here's what I wrote:
The most interesting bug I’ve solved disappeared when I tried debugging it.
I was comparing a sub-class of java.util.Date with a java.util.Date object using date.after(subInstance). However, no matter what dates I used, the Date always seemed to be after() the sub-class date.
So I naturally attached the debugger and after a bit of work identifying the correct line, I inserted a breakpoint. When the breakpoint tripped, I checked the variables list and everything looked appropriate, so I clicked run. And of course, the comparison now worked correctly. Scratching my head, I tried it a few more times and the comparison still worked.
Confused, thinking maybe I had inadvertently been using bad data earlier, I turned off the debugger and went back to work.
But the next time I tried it, it was still not working. So I turned the debugger on and set the breakpoint again and the comparison started worked again. I tested this multiple times and became convinced that running the debugger was fixing the bug!
The breakthrough came when I turned on the debugger and moved the breakpoint to a different line. This time the bug was still there!
Turns out the implementer of the subclass was concerned about performance when dealing with large numbers of date objects that would get deserialized from the database. So they wrote a lazy implementation of the Date class that delayed initializing many fields of the object until any method was called on the instance of the Date subclass.
When I used date.after(subInstance), no methods were called on subInstance. Its uninitialized fields were accessed directly, so it started at time 0.
When the breakpoint tripped, it would call toString() on the subInstance to display its value in the variable list, triggering the lazy initialization of the object and making the bug disappear.
Sunday, October 5, 2014
Giving to receive
When I give, expecting something in return, my motives become clear when my generosity is not reciprocated. I feel disappointed or bitter that the other person didn't return the favor. In this state, our relationship cannot improve because I have no joy in giving and they sense my displeasure. When I truly give to serve, my love is obvious and our relationship improves. Ironically, when I give without desiring anything in return, the other person will often sense my true generosity and be more likely to show love and care for me and bless me in return. We shouldn't confuse the returned favor as the reason we give; it's just a side benefit. We give because God gave so much to us and we want to share that with others.
Thursday, February 13, 2014
If it is, is id in it?
A question concerning existence using all five two letter words in the English language that begin with the letter 'i'.
Each word is a different part of speech: noun, pronoun, conjunction, verb, and preposition.
One example where all the words are used sequentially, but not in the same sentence -- and id is not really a word in this case.
Here's another instance of all the words being used in a single clause -- once again id is not really a word.
The common phrase "if it is in" uses 4 out of 5 of the two-letter 'i' words.
Each word is a different part of speech: noun, pronoun, conjunction, verb, and preposition.
One example where all the words are used sequentially, but not in the same sentence -- and id is not really a word in this case.
Here's another instance of all the words being used in a single clause -- once again id is not really a word.
The common phrase "if it is in" uses 4 out of 5 of the two-letter 'i' words.
Tuesday, December 10, 2013
No Regrets
No regrets means a couple things to me: first, living in such a way that you have no reason to regret the choices you've made.
Secondly, it can mean not regretting the decisions we have already made. If we are perfect in the first, the second follows naturally. Both definitions can be good rules for life.
But if we fail in the first (as we all will), the second meaning can have several different implications. It might mean never regretting what we've done, even if we were in the wrong. It is a position of pride. Alternately, we can view it as a learning experience, substituting regret with repentance and moving forward with our lives, knowing we can't change the past. It is a position of acceptance, from which, we are able to grow.
Monday, December 9, 2013
Memories
My dad banning me from reading children's books as a pre-teen. He wanted my reading to stretch me. I didn't like it at the time, but it has stuck with me and it has helped me to (usually) not seek simple filler but meaningful, thought-provoking reading material.
Social/conformity anxiety so great that I always relied on cues from others to determine how to act. When I worked with my dad, on the way home, I wouldn't roll down my window unless he did so first (and roll it up as soon as he did); I would not open my beverage unless he did first. Just one example of a lifelong pattern.
Social/conformity anxiety so great that I always relied on cues from others to determine how to act. When I worked with my dad, on the way home, I wouldn't roll down my window unless he did so first (and roll it up as soon as he did); I would not open my beverage unless he did first. Just one example of a lifelong pattern.
Friday, December 6, 2013
Tuesday, October 29, 2013
How to end sentences with two spaces in web forms
For those obsessed with double-spacing at the end of sentences, I created this bookmarklet that can be used to add two spaces that won't collapse into a single space when viewed on a web page. It finds text boxes on a web page and converts all double spaces in them to non-breaking spaces (unlike normal spaces on the web, multiple consecutive non-breaking spaces don't get reduced to a single space automatically). I'm not sure why you'd want to do this, though.
Subscribe to:
Posts (Atom)