In the last post, we explored the cause of Cincinnati’s sweltering 222°F forecast.  After I mused about variable declarations and improper usage that we saw with the 119° snow day, reader John offered a different idea - that 222° was simply a typo for 22°.   I think he’s right, but we didn’t fully test the hypothesis against the original symptoms.  My bad.

And as software debugging usually goes, testing and fixing one bug opens the doors for more of their friends to come out and play.

More Symptoms and Background Information

Last time, we noted that an Alerts box on the upper left was red, but reported zero alerts. Red usually means bad; did the software kinda detect a bug but not completely propagate the information through the system?

To gather more information I visited WLWT Weather to explore around.  Turns out that the Alerts box is red all the time, with the number of real alerts listed in the box.  Since the Alert # was zero on the 222 °F furnace day, this further supports that the 222 bug could be a typo as John mentioned, rather than an autogenerated forecast.  Otherwise, the Alerts value probably would have been a ‘1′.  Well, assuming that extreme temperatures of the Planet Mercury-type are even in the Alerts consideration along with tornadoes, snow advisories, frogs and locusts.

WLWT is in Cincinnati, Ohio.  I pulled up the weather forecast temperatures for Wednesday last week, shown below, and they look normal. However, the lower box looked odd.

“Thurs       Day        Night”

With no additional information.  But if you hover over a day like I did below (Thursday), more info is provided in the box.  The blue Forecast box near Alerts matches the Wednesday forecast at the bottom. Looks good except for the odd behavior of the lower box.

More Research Summarized

  • Hovering over a day enlarges the forecast box slightly so that additional “Day” and “Night” information is presented in the otherwise strangely blank box.
  • The website becomes less responsive - my browser reports repeated attempts to transfer data from “”  I run a plugin for stuff like ads and site meters.  You can see below that was blocked.  But it seems that doesn’t like that and begins sucking up nearly all available cycles trying really really hard to sell me something (gloves?).

Hmmmm, what if I check the weather outside of Cincinnati?  Let’s try Los Angeles:

Good Stuff

  • Alerts are still zero.  Which seems to be desired behavior.

Not So Good Stuff

  • Hovering over any daily forecast provides NO additional Day or Night information in the lower box.  And now the “Thu”, “Day”, and “Night” labels seem to correspond to Wed, Thu and Sat forecasts.  Hmmm.  Saturday with a Chance of Night.
  • Today Los Angeles will have a high of 62°F, while the upper forecast by the Alerts box remains at 34°F.  The webpage title *clearly* states “View Forecast for Los Angeles” - which is this page.   Huh?
  • Performance drops to a dead crawl.  WLWT now bangs away on  Also another site I block.

Cincinnati is not equal to Los Angeles

Beyond the obvious, check out the Process Explorer info below.  CPU cycles are on the top in green.  The left side shows CPU cycles when I was connected to the Cincinnati weather site - insanely high just to pull up a static weather report.  I had to close the browser window to stop it, dropping the CPU usage nicely back to reasonable values shown in the middle.

So I jumped back to WLWT and rechecked the weather for Los Angeles.  Again, CPU cycles on the right side are in the stratosphere, but THIS time it hogs so many cycles I couldn’t even close the window.  I had to kill the entire browser process to regain control of my system.

New Hypotheses

Dead crawl performance: I don’t develop websites with ad or site trackers - someone will have to clue me in.  When NoScript runs, I often get error windows where ads or tracking would appear (as below - but they don’t slow down my browsing experience at all.  The web page may not be “pretty” but I’m fine with this behavior.

For example:

  • The WLWT weather website is coded in such a way that the website and my browser are completely crippled when I block ad and tracking activity.
  • The website was tested for Cincinnati (since it’s the local station) more than for other locations.  I verified by checking Hawaii too (ahhhhhh) and found the same (bad) Los Angeles-like results.

But hey! When I checked the MAIN website, I found that it behaved much more nicely, bailing out when I said “No No” to the ad site (!


We’ve just seen a typical debugging concept at work - exploring and testing one hypothesis (for the 222°F bug) can bring up a rash of new problems.

  • With a little testing, we debunked the red Alerts box as being related to the 222°F bug. That’s good.

However, we found new problems.  (Someone pull up the defect tracking system.)

  • Performance for the Cincinnati weather site has better performance than for the 4 other locations in the US that I tested.
  • The main website handles my site blocking software for ad and site tracking websites very nicely.
  • However, degradation in performance for the site is related to inappropriate implementation of ad and site tracking.
  • Specifics for Day and Night forecasting appear for Cincinnati but for no other location I tested.
  • The upper and lower forecast blocks don’t match.  After checking different sites, it became clear that the upper block was always Cincinnati.  This is probably as designed, but the implementation is confusing to the user, and just plain poor user interface layout in general.
  • Manual entry of temperature data has insufficient error checking.

Take Home Message

I didn’t intend to track the 222°F bug this far, but sometimes this is what happens when you hunt for one bug … they invite their friends.

What do you do in this situation?  Document the new bugs however you would normally - a defect tracking system, a notebook or spread sheet - whatever is standard for your situation.