I haven’t had a lot of time for carving lately, what with home repair projects and Springtime yard work. When I have had time, I’ve been working on these little guys.

They’re supposed to be bears. Some say that they look like dogs. I don’t much care what other people think they are. They’re cute.

From left to right, the woods are sycamore, sycamore, Bradford pear, and apricot. Pear bear is right at three inches tall.

Bike gets paint

After 10 years and 20,000 miles, the bike had some rust spots and lots of scratches from where I’d laid it down a few times.  My first inclination was to sand the areas and primer/paint them myself.  But the more I got into it, the more convinced I became that I wouldn’t be able to do a good job and the result would look terrible.

I disassembled as much as I could, paid the bike shop $20 to do what I couldn’t (several things require the use of some very expensive tools), and took the frame to Accent Powder Coating.  Then back to the bike shop for reassembly.  For less than $500, I have what is essentially a new bicycle.

Can’t wait to go for a ride.  You can click on the picture below for the full-size image.

Memory leak in ConcurrentQueue

I learned today that there is a memory leak in the .NET 4.0 ConcurrentQueue class. The leak could explain some trouble I was having in December with a program running out of memory. I didn’t know about this bug at the time, but reducing the sizes of several of my queues seems to have made the problem go away.

I know some of you are thinking, “A memory leak in .NET?  I thought the garbage collector was supposed to prevent that!”  The garbage collector collects garbage–memory that’s no longer referenced.  It can’t collect something that’s still being used.  Let me explain.

The ConcurrentQueue class uses an array as its backing store.  When an item is added to the queue, a reference to the item is placed in the array.  As long as an item is in the queue, there is an active reference to it–some part of the program is depending on that item to be good.  In garbage collector parlance, the item is “rooted,” meaning that the garbage collector can’t collect it.

When an item is removed from the queue, that item’s slot in the array is supposed to be cleared–set to null. Since the item was removed from the queue, it makes no sense to keep a reference to the item around.  And as long as the queue keeps the reference, the garbage collector can’t collect the object.

Problem is, the code that removes items from the queue doesn’t clear the item’s slot in the array.  The result is that stale object references remain in the queue’s backing array until one of the following happens:

  1. An item added to the queue overwrites that slot.
  2. There are no more references to the queue (i.e. it goes out of scope).
  3. The array is resized. This happens automatically as the number of items in the queue grows and shrinks.

There might be other ways, but those are all that I can think of at the moment.  The point is that items “live” in the queue longer than they absolutely have to, which is a potentially serious memory leak.

I say “potentially serious” because it’s not like the queue grows without bound. At least, it shouldn’t. If your program allows for unbounded queue growth, then you have a more serious problem than this memory leak.  That said, with the existence of this bug you have to assume that your queue will always have worst-case memory usage.  That is, for the purpose of computing memory consumption, you have to assume that the queue is always full, even when you know that all items have been removed.

This can be a real problem if you use a queue to hold input items, for example, and a separate collection to hold items that have been processed from the queue. For example, imagine a loop that does this:

QueuedThing queued = GetNextItemFromQueue();
ProcessedThing processed = ProcessThing(queued);

Your expectation is that, within the limits of the garbage collection interval, the amount of memory used is:

(sizeof(QueuedThing) * queue.Count) + (sizeof(ProcessedThing) * list.Count)

But with this bug, you have to design for the worst case memory usage, which is:

(sizeof(QueuedThing) * queue.Capacity) + (sizeof(ProcessedThing) * list.Count)

So if QueuedThing and ProcessedThing are the same size, then your worst case memory usage is double what it should be.

Microsoft says that the fix for this will be in the next version of .NET. Considering that .NET releases are typically every two years or so, that means at least another year before this is fixed.  Until then, the workaround is to be more careful with the way you use ConcurrentQueue (and BlockingCollection, which uses a ConcurrentQueue as its default backing store). In particular, you should be careful to limit the size of your queue and limit the scope in which the queue is active.

Positioning problems

I’ll admit up front that I know very little about CSS–just enough to be dangerous. As a result, I’ve been struggling with creating the layout for a new Web site.  I’ve been doing everything else possible, but today I just had to do something to rationalize things. So I sat down with a book: CSS The Definitive Guide.

If this is the “definitive” guide, we’re in trouble. CSS is confusing, and this book doesn’t do much to lessen the confusion. I don’t have the time or the inclination to write a full review of a book that was published in 2006.  Suffice it to say that I very highly recommend that you find some other book to get your information from.

One thing I’ve had a lot of trouble with in CSS is positioning elements on the page–making things appear where I want them to. So I turned to the “Floating and Positioning” chapter of the book, which appears to have a reasonably good discussion of the topic.  I say appears because it turns out that the book’s description of the offset properties in the “Basic Concepts” part of the chapter is completely misleading:

[The offset] properties describe an offset from the nearest side of the containing block (thus the term offset). For example, top describes how far the top margin edge of the positioned element should be placed from the top of its containing block.

Whereas that’s true for absolute positioning, it’s not at all true for relative positioning. The offsets for relative positioning, as the book points out 30 pages later, are offsets from where the element would normally be positioned.  With relative positioning, the offsets have nothing to do with the edges of the containing block.

It’s nice that the book eventually points out the difference, but failing to call out the difference in the overview discussion is a grave omission.

The implementation of CSS falls far short of the goal of creating a robust, easy to use, and easy to understand language for specifying the layout and appearance of Web pages.  There are times when I think that the whole of CSS is a joke perpetrated by people who are laughing at those of us who try to use it.

If I didn’t laugh, I’d cry

Life is funny.  So are home repair projects.  At least that’s what I tell myself. Otherwise I’d just go crazy.

Last weekend I had a friend come over and help me with replacing the … whatever it’s called … that goes on the bottom of the outside door.  It’s the thing that closes the gap between the bottom of the door and the threshold.  I went to Home Depot and, although I couldn’t find exactly what I wanted, got something close.  Mike came over and helped me take the door off (it’s a heavy door and a two-man job).  We took off the old strip, screwed the new one on, and re-hung the door.

Satisfied with a job well done, we grabbed a couple of beers and went to sit outside.  Debra came out a while later to inform us that there was a “huge gap” under the door.  Sure enough, the thing I picked up at Home Depot wasn’t big enough to cover the space between the door and the threshold.  Debra picked up a new one at Lowes, so I’ll have to install that one this weekend.

Yesterday afternoon, Debra noticed that one of the valves outside had a pinhole leak. We’ve had trouble with this valve freezing before. It’s on the north side of the house and if we get a few days of freezing temperatures in a row, the valve freezes and cracks.  We’ve tried lots of ways to prevent that, none of which have worked well. So one of the things I’ll need to do before next winter is build a box with a little heater (probably a 100 watt light bulb) in it.  But that’s next year. The valve needs to be replaced now.

The intent was for me to take the valve off this morning, go get the replacement, and install it.  But then my truck started running rough last night when I was on my way home.  So the plan this morning was for me to turn off the water, remove the valve, have Debra to follow me to the shop where I’d drop off my truck, and then have me drop her off at work so that I could have the car to go back home and install the new valve.  A little wrinkle but simple enough, right?

At first light this morning I walked up to the meter (about 300 feet from the house) and turned off our valve.  I went back to the house, turned on the faucet to drain the lines, and … the water kept running.  Looks like my water shutoff valve at the street is broken.  Okay, so it’s 20+ years old. I’ll have to replace that next.  But there’s another valve:  the service valve on the other side of the meter (the one that the water company can use to shut off my water and then lock).

So back up to the meter to turn off the service valve.  I really need to get one of those keys, because turning the thing with a pair of pliers is a pain.  I turned it perpendicular like I’m supposed to, trudged back to the house, turned on the faucet and … the water kept running.  Great.  I can slow the water flow, but can’t stop it.

With no way to turn off the water, we took the truck to the shop and then headed out to take Debra to work.  I called the water company to inform them of the broken valve. They didn’t believe me, but agreed to send somebody out “sometime today.”

Debra works for a pipe company, so I talked to one of the guys in the warehouse. After a bit of discussion I hit on the idea of taking the valve off (with the water still on) and then capping the pipe.  Should work, provided I can reduce the water flow enough so that the pressure doesn’t prevent me from putting the cap on.

Back at home I turned off both valves at the meter, attached a hose to the faucet that’s also attached to where the valve is (there’s a “T”), ran the hose to the middle of the yard, and turned on the water.  Then, armed with a pipe wrench, I began removing the broken ball valve, knowing full well that I was going to get wet.  And I did.  Drenched.  But I was successful in removing the valve and attaching the cap.  So at least now there’s no leak.

What was going to be a simple 1-hour job (including running for parts) turned out to be about three hours, and I’m only half done.  Plus, there’s another job I have to do–replace the valve at the meter.  On the plus side, if my valve hadn’t gone out I wouldn’t have discovered that the service valve was faulty.

The water company guy called me this afternoon to say that their valve at the meter was indeed broken, and that he’d replaced it.  It was nice to know that I’m not totally crazy.  And there really was something wrong with the truck. One of the ignition coils went out, so only half of the cylinders were firing.  I had them replace both coils, figuring that if one went out after 15 years then the other is likely to go soon, too.  Most of the cost is labor, anyway, and most of that is removing all the shrouds and such so you can get to the dang coils.

So, yeah, I laugh.  I could get angry or sad, but that wouldn’t help anything.  At least laughing means that something good comes from these unexpected events.

One problem with GUIs

One of the problems with GUIs that provide a “user friendly” interface to a command-line-oriented system is that if the GUI designer decided not to implement a particular feature then you’re left scratching your head.

I created a user-defined table in SQL Server today, and tried to use it from a stored procedure.  SQL Server didn’t like that.  It said:

The EXECUTE permission was denied on the object 'MyTableType', database 'MyDatabase', schema 'dbo'.

Okay, fine.  I’ve been here before with stored procedures.  So I pull up the properties for the user-defined table and … there’s no checkbox for the Execute permission.  Huh?

Now I know that SQL Server gurus do all their configuration with T-SQL commands.  That’s cool.  Really.  But I’m just a lowly programmer, not a white-coated DBA.  I stay as far away from databases as I can most of the time ’cause whenever I mess with them I end up with bites and scars.  But we don’t have the luxury of hiring a DBA, so I get to consult Google for how to set permissions.

It turns out not to be too difficult.  Just a few minutes’ looking around gave me this command:

grant execute on type::dbo.MyTableType to MyAppName

And now when I look at that object in the GUI, the Execute permission is shown.  Again I say, “Huh?”

Moral: You can’t administer SQL Server with just the GUI.  You’re going to learn some T-SQL whether you want to or not.



A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.