Bug Watch July 2004

Cadalyst's 20th Anniversary Bug Watch Awards continue with Part Two of Top Ten Bugs.

Although I've been writing Bug Watch only since 1995, my history of handling AutoCAD bugs goes back a decade further. Back in 1985, I performed technical support for an AutoCAD dealer. I was trying to solve a problem the client was having with AutoCAD v2.17 plotting to a Houston Instruments DMP-52 plotter. Plots would start out fine, but then the device would suddenly develop mad plotter disease. It sent vectors wildly all over the place, ruining the plot. Long hours were spent shuffling back and forth between the dealer and the client site, soldering endless variations of serial cables, testing, retesting, and finding that nothing helped. I seem to remember that it took the next version of AutoCAD to solve the problem. Fortunately, the client was an architect who wasn't really interested in using CAD for serious production work. He just wanted something that looked high-tech to impress his clients. As long as he didn't plot in front of them, he got away with it.

I didn't even know I'd been fighting an AutoCAD bug until some years later, when an Autodesk person made a throwaway comment about it on the CompuServe ACAD forum. If I had known that at the time, it would have saved me huge amounts of blood, sweat, and tears. That episode taught me that it's not possible to have too much information about AutoCAD bugs. This slightly unhealthy obsession eventually led to my being nicknamed the Bugwhan in certain circles. I made a suggestion in Bug Watch July 1997 that readers should send me money and gifts instead of bugs, but unfortunately that idea never caught on. Instead, all the awards and glory must go to Autodesk. Here are the final five Bug Watch Awards, completing the Top Ten we started last month.

Help the aged award
This is the oldest surviving Bug Watch bug. Mike and Mark reported it in the second-ever Bug Watch in February 1993. It existed in Release 12c1, and maybe even Release 11. It still exists in AutoCAD 2005:
Paper space zooms to outer space
When you perform a Zoom Extents (or Zoom All) in a paper-space viewport, Release 12 incorrectly includes entities on VPFrozen layers when computing the extents. For instance, draw a small circle at 0,0 on layer LL, and another one at 1000,1000 on layer UR. Change TILEMODE to 0, create a viewport with Mview, and use VPLayer Freeze to freeze layer UR in the new viewport. Now use Mspace to enter the viewport and perform a Zoom Extents. Release 12 should zoom tight around the lower left circle, but instead it zooms way out so that the upper right circle appears as if its layer were VPThawed.
Workaround: Put the offending entities on a separate layer and use Layer Freeze instead of VPLayer Freeze. Alternatively, define a view showing the area you want to see and use View Restore instead of Zoom Extents.

History repeated itself a decade later in September 2003, when, unaware of its earlier outing, I reported the same thing in different words:
Extents elusion (R14 to 2004)
The Zoom command's Extents option displays all of the objects in the drawing using the largest possible magnification. This should include objects on layers that are turned off but not those on frozen layers. That is true for layers that are frozen globally, but AutoCAD gets it wrong with viewport frozen layers. If you freeze layers in certain viewports and Zoom Extents, the objects on those layers are included in the calculation of the extents. If those objects lie outside the true extents, the magnification will be too small.
No known workaround.

Ephemeral abnormality award
The shortest-lived AutoCAD bug I can recall is the HP plot problem introduced by AutoCAD 2004's Service Pack 1, as reported in November 2003:
AutoCAD 2004 Service Pack 1a
AutoCAD 2004 Service Pack 1 was released, and then rapidly withdrawn. It introduced a plotting problem with some HP devices, but Autodesk moved commendably quickly to correct this. A minor patch to correct the plotting problem, the HPGDI8.HDI Service Pack 1 Update, was made available within 24 hours. This was followed by an updated Service Pack 1a, which replaces Service Pack 1 and includes the plotter patch. Service Pack 1a can be applied on a virgin AutoCAD 2004 installation or one with the original short-lived Service Pack 1, with or without the HPGDI8.HDI patch.
This was quite outstanding work by Autodesk. Where there are humans, there will be human error. What matters is how those inevitable errors are dealt with. It's difficult to imagine a better way to handle this error.

Best up-and-coming bug award
The award winner for the bug with most promise for the future goes to the bug below. I cheated a little with this one, because it never actually appeared in Cadalyst. However, it did appear from October 1995 as item 348 in my unofficial Release 13 Bug List, which was regularly promoted in Bug Watch.

Year 2038 bug (R13)
If you set the system time and date to around 03:14:15 and 19 January 2038, then start Release 13, it crashes with an unhandled exception error (sometimes).
Workaround: Try to find an alternative CAD package some time in the next 40 years or so.
This is actually my favorite AutoCAD bug of all time, because of the occasion on which it made me look like a genius! I was once called in to a large site to try to solve a mysterious problem that had beaten the best efforts of the on-site support guy, the local dealer, and Autodesk's dealer support. AutoCAD Release 13 had been installed in an identical way on a bunch of identical PCs. Most of the copies crashed on startup with the quite common and infamously uninformative unhandled exception error, which just means, "Here's an error we never thought of when we wrote this program." One PC worked fine, and they could not figure out why.

I went to work on one of the problem PCs, checking various things that could cause Release 13 to get upset. Then, in a flash of inspiration, I checked the PC's date. It was set to 2080. I changed it to 1996, called the support guy over and asked him to start up AutoCAD. When it fired up flawlessly, he was flabbergasted. All of the PCs had been delivered with system dates set to 2080. On the one that worked, the support guy had noticed it at some stage and fixed it, then forgot about it. When I told him the secret, he said, "I would never have thought of that in a million years. What on earth made you think of checking the date?"

In truth, there was nothing really clever about it. I just remembered something I had written a few months earlier. I didn't even discover the bug in the first place. But it sure made me look good!

The spoilsports at Autodesk "fixed" this bug in Release 14 by checking the date at startup, and if it's after 2037, offering to set it back to 1997. I've since learned that this bug affects all sorts of software because of the way a standard time data type is defined as an integer in C and C++ programs. On 19 January 2038 at exactly 3:14:08 A.M., that integer will wrap around to a negative number representing 8:45:52 PM on 13 December 1901. This will confuse a lot of programs and make others crash. For more details, see here or here.

Living dangerously award
Every so often, subtle bugs come along with the potential to massacre innocent drawings. Release 13 had more than its fair share of these. This one from January 1997 is probably the nastiest:
Rewriting history (Windows 13c4a)
Draw a few lines in an unnamed drawing. Next, pick a drawing from the File pull-down menu's recent file history. A dialog prompts you to save the current drawing. Pick Yes. At this point, AutoCAD gets confused. It prompts you for the name under which the current drawing should be saved, and it answers its own question with the name of the file you selected from the history. If you don't have at least three lines in your command prompt area, you won't see this. Next, AutoCAD asks if you want to replace the existing drawing. If you agree, the file you selected from the recent file history is overwritten by the contents of the current drawing.
Workaround: Be careful. Be very, very careful.

This bug from March 1997 is pretty evil too:
Escape scrape (Windows 13c4a)
If you are in an existing named drawing and you open another drawing, as soon as you pick OK in the Open dialog box, AutoCAD changes the DWGNAME variable to reflect the selected drawing. That's fine if the command proceeds normally. If you change your mind and press Esc, AutoCAD cancels Open. The current drawing remains in memory, and the current drawing name is displayed in the AutoCAD title bar and the task bar. Everything looks fine, but AutoCAD's out-of-sync DWGNAME means you are in danger. Any Qsave you perform from then on saves the current drawing under the wrong name, overwriting the drawing you selected before you canceled Open. The correct drawing file won't be updated.
No known workaround.

Corporate image award
This one from April 1997 also deserves an award for the most trivial bug. Trivial or not, though, I'm confident that today's Autodesk wouldn't tolerate such a thing as this in AutoCAD for three whole releases:
Square dance (Windows 11-13c4a)
If AutoCAD is configured to use monochrome vectors, the Autodesk logo displays as a solid white or gray square.
No known workaround.