Bug of the moment 2007-04-18
There are a couple of things I want to share, so another entry today.
I was reviewing the manual to my motherboard last night, which is comprised of three Acrobat files. I opened the first, skimmed it, and then opened the second. The first sign of something being afoot was that I now had two taskbar buttons, in reverse order: 6117-2.PDF followed by 6117-1.PDF. I am running Windows 2000, and as such, Explorer has neither desire nor inclination to rearrange taskbar buttons. But here, Adobe Reader appeared to have inserted a new button in between two existing ones.
However, I felt sure that Adobe Reader was an MDI application. Sure enough, all three PDF files shared a single window. Three taskbar buttons all sharing a single window. (“The Mormons are from Mars, Dad, we had it checked…”)
It seems that Adobe have decided to pull a strange stunt to find a compromise between MDI and SDI, by creating dummy taskbar buttons that point into children of the parent window:
I am honestly not sure whether this is a good idea or a bad idea, either as a hack, or as a fully-supported concept. It certainly violates concepts such as control-clicking multiple taskbar buttons and selecting a Tile context command, as there is only one top-level window between them. Sometimes I wonder what system Adobe think they are developing for.
Like the last entry, I started out with a non-bug. So here is a bug.
Mozilla software has (as I have probably said) a bizarre, narcissistic requirement to open a TCP connection to itself and send itself fan mail all day long. When my peer-to-peer client overwhelms the TCP stack (itself a bug and a half, see 20/07/2006’s entry), the application can no longer send data down this socket and will fail to function. Thunderbird will immediately lock solid. Firefox will normally fail to open any more pages until you reload it. Clearing out the TCP stack does nothing: you have to terminate the connection, whereupon the application will throw a paddy and eat 100% CPU until restarted.
At this stage, I’d nuked Thunderbird, and then closed Firefox and restarted it. I closed the peer-to-peer client also and tried to restart it via the Start menu, but Explorer froze, leaving the taskbar almost entirely blank, with a hole where the Start button should be:
I hit control-alt-delete and opened Process Explorer, and launched the program from there. I didn’t want to terminate Explorer (as it affects one-click-minimise on restart) so I left it, empty and dead. The system tray was accepting new icons and redrawn icons, but not context clicks or tooltips.
I was wondering just what exactly had frozen Explorer, and eventually spotted that there were two instances of Firefox running. You can see this in the screenshot above. What had happened is that Firefox had locked up when I tried to close it, but after the point where it had closed its window and flushed the session out, and released the lock file. This allowed a second Firefox process to start, while the old one was still eating nearly 100 megabytes of memory. Killing the old Firefox process released Explorer, and thus the original request to start my peer-to-peer client suceeded. (Thus resulting in two concurrent instances, and one of those – obviously – crashed.)
I also noticed that Process Explorer was running twice: when I’d invoked it via the Windows Security dialog, the new instance had obeyed the Allow Only One Instance setting, focused the existing process, and promptly crashed.
I do hope Linux and BSD desktops don’t end up in this mess. In my case, I can deal with it with a cool head and keep my uptime alive, although technically I am probably cheating.
Posted 18th April 2007 – Comments and questions?