CDR Tickets

BZDATETIME::2011-04-01 13:27:32
BZCOMMENTOR::Volker Englisch
BZCOMMENT::1

---Original Message---
From: Alan Meyer vrmeyer@comcast.net
Sent: Thursday, March 31, 2011 7:15 PM
To: Englisch, Volker (NIH/NCI) [C]
Cc: Kline, Robert (NCI)
Subject: Re: DST

On 3/31/2011 5:43 PM, Englisch, Volker (NIH/NCI) [C] wrote:
> FYI:
>
> Diana noticed that the QC reports that are displaying a time stamp using the filter function 'cdrutil:/date' are currently not displaying the time as DST but EST.
>
> Is there a library that should be updated to display the local time correctly? I don't think the date/time format used is incorrect.
> 'cdrutil:/date/%25B %25#d, %25Y %25#I:%25M% 25p'
>
> Should I add an issue for this?
>

I think we should.

I wrote a little program to see what's going on:

• • • • • • • • • • cut here -----------
                    #include <ctime>
                    #include <iostream>

int main() {
char buf[1024];
const char* format = "%Y-%m-%dT%H:%M:%S.000";
time_t tod = time(NULL);
strftime(buf, sizeof(buf), format, localtime(&tod));
std::cout << buf << std::endl;

struct tm *tmst;
tmst = localtime(&tod);
std::cout << "isdst=" << tmst->tm_isdst << std::endl;

return 0;
}
-------— end --------------

At 7:10 pm tonight (19:10 in 24 hour time) the output of the program was:

2011-03-31T18:10:26.000
isdst=0

We're off by an hour.

The tm_isdst is supposed to tell us whether it is standard or daylight
savings time. 0 = standard, >0 = daylight savings.

Looks like the old Microsoft daylight savings time bug.

BZDATETIME::2011-04-01 13:28:25
BZCOMMENTOR::Volker Englisch
BZCOMMENT::2

---Original Message---
From: Kline, Robert (NCI)
Sent: Friday, April 01, 2011 10:41 AM
To: Englisch, Volker (NIH/NCI) [C]
Cc: Alan Meyer
Subject: Re: DST

> Should I add an issue for this?
>

Sure. This is probably related to the bug behind KB932299. I tried
downloading and installing the patch, but the Windows Installer wasn't
up to the task. Here's what I posted on Microsoft's discussion board:

KB932299 patch installation fails

"The upgrade patch cannot be installed by the Windows Installer service
because the program to be upgraded may be missing, or the upgrade patch
may update a different version of the program. Verify that the program
to be upgraded exists on your computer and that you have the correct
upgrade patch." The upgrade patch is VS7.1-KB932299-X86-Enu.exe. The KB
article lists the following software in the "applies to" section:
The C Run-Time (CRT)
Microsoft Visual C++ .NET 2003 Standard Edition
Microsoft Visual Studio .NET 2003 Academic Edition
Microsoft Visual Studio .NET 2003 Enterprise Architect
Microsoft Visual Studio .NET 2003 Enterprise Developer
Microsoft Visual Studio .NET 2003 Professional Edition

We are running VS.NET 2003 with service pack 1 installed on Windows
Server 2003 R2 Enterprise Edition with Service Pack 2. Any clues?

BZDATETIME::2011-04-05 09:53:25
BZCOMMENTOR::Bob Kline
BZCOMMENT::3

The good news is that the bug went into hiding this past Sunday morning, because at that point we passed the kickoff time for DST as it was before Congress moved it a few years ago. This gives us plenty of time to shake the tree at Microsoft to tell us what magic incantations we need to perform in order to convince the patch installer to work. The bad news is that it won't be easy to test until this fall, when we hit the gap at the other end between when Microsoft's broken DLL thinks DST ends (October 30 this year) and when it will actually end (November 6). Ideally we will have applied the patch successfully and tested it (somehow).

BZDATETIME::2011-04-08 17:14:04
BZCOMMENTOR::Bob Kline
BZCOMMENT::4

I did some further experimenting, and found that you can either install SP1 for Visual Studio 2003 or the KB932299 patch to fix the DST bug, but not both, which is surprising, since the patch was released a year after the service pack (and I've confirmed that the service pack does not include the fix for the DST bug). I assume that we were able to apply the KB932299 patch to VS2003 on Mahler originally because we hadn't installed the service pack. When we rebuilt Mahler most recently we applied SP1 when we re-installed VS2003. I have asked Mauricio for a service incident from the support pack CTB purchases from Microsoft (I assume they still do that) so I can open a ticket with MS. If we don't have access to support any longer, or if Microsoft refuses to solve the problem, we have the following options:

1. remove the service pack and apply the bug-fix patch
2. upgrade the CDR Server and client DLL to VS2005 or VS2008
3. rewrite the server in .NET and replace XMetaL/CDR DLL
4. implement a workaround in the CDR server and client DLL
5. live with the bug
6. keep SP1, but distribute patched runtime DLLs
7. rebuild Microsoft's runtime DLLs from patched source code

The first solution is basically how we dealt with the problem before rebuilding Mahler, and it's one of the least intrusive and cheapest options available. It's difficult to tell what risk this would involve. Reviewing the list of problems [1] addressed by the service pack doesn't help as much as you would think, because the descriptions of those problems are pretty vague. For example, "If you turn on optimization, your generated code may not be correct": does that refer to managed .NET code or unmanaged C+? Reading the linked KB article for that problem doesn't help much: all it says is "If you turn on the /Og optimization, the /O1 optimization, or the /O2 optimization, the Generate Assembly instruction incorrectly loads the AL register value instead of the AH register value. Therefore, you may receive incorrect output from your application." The "Assembly" in this sentence probably refers to managed .NET applications (which) wouldn't affect us, but we can't be sure it doesn't refer to generation of assembly language from C+ code as an intermediate step on the way to creating an executable binary object. Most of the problems listed as addressed by the service pack clearly don't apply to us (problems with the IDE, for example, or ISAPI), but there are a number that might:

• [327097] Visual C++ .NET compiler generates two different native types for the same Boolean return type

• [821423] Bug in the Vector header file causes applications that use <bool> specialization to quit unexpectedly

• [823020] Compiler-optimized code may cause loops to terminate early

• [828100] "The parameter is incorrect" error message when you open a file from a CD-ROM in a Visual C++ MFC application that was created in Visual Studio .NET 2003

• [830890] Call to the ATL __unhook statement returns E_FAIL

• [831380] A Visual C++ 2003 MFC application quits silently when the OnDraw function is used and optimization is turned on

• [831537] The compiler may generate incorrect assembly code for templated classes that do not have a default constructor

• [832904] If you turn on optimization, your generated code may not be correct

• [834421] You may receive results that are not correct when you perform mathematical computations that involve floating point arithmetic in Visual C++ .NET 2003

• [837895] An access violation occurs under low memory conditions in your Visual C++ .NET application

• [841629] The compiler does not call an overridden copy constructor in Visual C++ .NET 2003

• [841772] The release build of a Visual C++ .NET 2003 application does not initialize arrays as they were defined

• [843148] Dynamic initialization does not work as expected in Visual C++ .NET 2003

• [872941] You may experience inaccurate results when you compile a project in Visual Studio .NET 2003 with either the /Og or the /Ob2 flags for optimization and then try to perform floating-point operations

• [873416] Byte values are not swapped correctly when you turn on the /Og code optimization option or the /O2 code optimization option in Visual C++ .NET 2003

• [884030] A Microsoft Foundation Class (MFC) program that was created in Visual Studio .NET 2003 unexpectedly quits when you try to close it

• [887185] Incorrect code is generated when you compile a Visual C++ .NET 2003 application that contains an inline method that accesses a static variable

• [889095] An MFC application stops running when a thread deadlock condition occurs in Visual Studio .NET 2003

• [890940] The strupr function may not convert strings to uppercase in Visual Studio .NET 2003

• [892086] Application leaks a handle when you call the CRT _popen function in Visual C++ .NET 2003

• [900811] The resulting application generates incorrect calculation results when you use Visual Studio .NET 2003 to build a Visual C++ project that performs calculations

Not sure how long it would take to pursue the second option, but it wouldn't be a trivial task: I would guess at least 40 hours. Presumably we'd reap other benefits from such an upgrade, assuming the bugs introduced by the later versions of Visual Studio are fewer/less severe than the bugs which are fixed, which seems like a reasonable assumption. Don't know whether that makes the option worth while, though, especially if we'll be told some day to pursue option 3 anyway.

The third option is surely the most drastic and expensive. We may be told to take on one or both of the tasks involved in this option at some point in the future, but I wouldn't recommend it as the immediate solution to this bug.

The fourth option would involve trying to come up with a replacement for Microsoft's logic for determining what the current date/time is, which we would implement in the code for the CDR server and in the client DLL. Without further investigation we can't say for certain that it would be possible to do this in a way which would work successfully for all possible versions of the runtime DLLs which could be loaded on the client machine running any version of Windows (including future versions which haven't been released yet), but it seems likely that we could pull it off. Not trivial or pretty, but certainly less effort than the previous two options.

The fifth option involves the least effort and expense, and in a sense it may be what we've been doing all along on the client side, since we don't have direct control over which run-time DLLs are loaded on the client machines, and it's in the run-time DLLs that the bug lives. It's possible that we don't currently have any code in the client DLL which is affected by the DST bug, other than possibly incorrect time strings in the debugging log, and perhaps not even there. Even if the bug only affects the server, however, just "living with the bug" means that at least some of the reports, and possibly other processing would be affected for several weeks out of each year.

The sixth option would represent a compromise between the first and fifth options: we'd have the benefit of fixing the bug (at least on the server side, which is probably the only place it affects us), as well as having bugs which affect compiler output and which are fixed by the service pack eliminated. We can't know for certain which of the bugs listed above are in which category (compiler output or runtime libraries), given the vagueness of the bug descriptions.

The last option is unattractive from several vantage points: it involves a non-trivial amount of work to determine what needs to be fixed; we'd have to do it again if any other service packs came out (though that's unlikely at this stage), and it would be difficult to make sure we didn't break anything critical but subtle while we were doing it.

In summary, none of the options is without drawbacks. At this point, I'm leaning toward option two. Looking at the list of bugs fixed by the service pack (and the list above is a small subset) I can only imagine the size of the pile of bugs which have been found and fixed by the later versions of Visual Studio. But let's see if we can get Microsoft to solve the problem before we make a decision.

[1] http://support.microsoft.com/default.aspx?scid=kb;en-us;918007

BZDATETIME::2011-04-18 11:43:12
BZCOMMENTOR::Bob Kline
BZCOMMENT::5

Just sent Mauricio a reminder that I'm waiting for him to give us a ticket so we can open a case with Microsoft.

BZDATETIME::2011-04-20 11:52:12
BZCOMMENTOR::Bob Kline
BZCOMMENT::6

(In reply to comment #4)

> In summary, none of the options is without drawbacks. At this point, I'm
> leaning toward option two. Looking at the list of bugs fixed by the service
> pack (and the list above is a small subset) I can only imagine the size of the
> pile of bugs which have been found and fixed by the later versions of Visual
> Studio. But let's see if we can get Microsoft to solve the problem before we
> make a decision.

I found Server/README.vs2008 in our version control archives. Apparently I had already done some of the work on this upgrade some time back. Still waiting for Mauricio to get me what I need to open a case with Microsoft.

BZDATETIME::2011-04-22 11:12:37
BZCOMMENTOR::Bob Kline
BZCOMMENT::7

Opened case 111042254443027 with Microsoft (a process which has gone from very simple and straightforward to a multi-day painful ordeal).

Incident title:
Unable to install VS7.1-KB932299-X86-Enu.exe to VS 2003 SP1

Problem description:
We have an installation of Visual Studio 2003 on our development server. We have applied Service Pack 1, which was released September 2006.[1] We are trying to apply the bug fix for the DST bug (KB932299)[2], which was released in February of 2007, but the Windows Installer fails with an error message claiming that it cannot find the product to which the patch belongs. If we back out the service pack, the Windows Installer is able to apply the KB932299 patch successfully, but then we are unable to reinstall the service pack unless we remove the KB932299 patch. What do we need to do to get the installer to recognize that VS2003 SP1 is the version of Visual Studio which was current at the time the KB932299 patch was released?

[1] http://www.microsoft.com/downloads/en/details.aspx?familyid=69d2219f-ce82-46a5-8aec-072bd4bb955e&displaylang=en
[2] http://support.microsoft.com/kb/932299

BZDATETIME::2011-04-26 08:28:24
BZCOMMENTOR::Bob Kline
BZCOMMENT::8

Persistence paid off. It took several days to open the case with Microsoft, but once I did the results were swift and satisfactory. The rep handling the case gave me a secret (that is, not publicly available) version of the KB932299 patch which is installable over VS2003 SP1. I have installed the patch on Mahler, and the fixed runtime DLLs have been deployed to all three CDR Windows servers in d:\cdr\bin, where they are automatically loaded by the CDR Server software. I verified that the corrected DLLs fix the Daylight Savings Time bug on Mahler and Franck by setting the clock back temporarily on each server to a point in the three week window during which DST should have been in effect but the old DLLs thought standard time was still in play. I believe this task can be closed, though you may want to test yourself on Franck or Mahler with the QC filters that Diana was using, using the trick of setting the server's date back (temporarily, please) to March 30, 2011, Volker.

BZDATETIME::2011-06-15 11:35:24
BZCOMMENTOR::Volker Englisch
BZCOMMENT::9

I ran the command
Control timedate.cpl
to temporarily adjust the date. The report listed "June 15, 11:30am" before adjusting the date and "March 30, 10:30am" after adjusting the date.

All is well - closing issue.