"Terminated in an unusual way", But Only in Europe
-
This one's not mine. I came across it at http://www.experts-exchange.com/Operating_Systems/WinXP/Q_22150503.html[^], but it seems to fit the "subtle bugs" category and I wanted to share it here. The developer had an internationally-deployed application which, apparently after a version upgrade, began to fail reliably with the message "The application has requested the Runtime to terminate it in an unusual way." However, the failure occurred only in Europe; the failure was not reproducible in the US. He tried linking with the "/MAP" linker option, and changing his WinMain code to install an exception handler that would allow him to see where the failure occurred. However, the failure was occurring before any of his code was executed, so it was failing even before the exception handler could be installed. After a false lead involving a possible flaw in the Microsoft assert() code, he eventually traced the problem to an initialization of a static variable (which of course is initialized by the CRT before any of his code is executed). Here is the developer's explanation of the problem and his solution:
A Smart Developer wrote:
What it turned out to be was the initialization of a static variable to what amounted to a negative time for anyone east of Greenwich:
static CTime distantPast = CTime(1970, 1, 1, 0, 0, 0);Once I set my time zone to Berlin, the debugger found the problem in about 5 sec. The fix was very simple (2-Jan-1970 serves fine as the "distant past" for my purposes).His answer also suggests a good programming practice about initialization of date-related variables (i.e., January 2nd, not the 1st). Mike
-
This one's not mine. I came across it at http://www.experts-exchange.com/Operating_Systems/WinXP/Q_22150503.html[^], but it seems to fit the "subtle bugs" category and I wanted to share it here. The developer had an internationally-deployed application which, apparently after a version upgrade, began to fail reliably with the message "The application has requested the Runtime to terminate it in an unusual way." However, the failure occurred only in Europe; the failure was not reproducible in the US. He tried linking with the "/MAP" linker option, and changing his WinMain code to install an exception handler that would allow him to see where the failure occurred. However, the failure was occurring before any of his code was executed, so it was failing even before the exception handler could be installed. After a false lead involving a possible flaw in the Microsoft assert() code, he eventually traced the problem to an initialization of a static variable (which of course is initialized by the CRT before any of his code is executed). Here is the developer's explanation of the problem and his solution:
A Smart Developer wrote:
What it turned out to be was the initialization of a static variable to what amounted to a negative time for anyone east of Greenwich:
static CTime distantPast = CTime(1970, 1, 1, 0, 0, 0);Once I set my time zone to Berlin, the debugger found the problem in about 5 sec. The fix was very simple (2-Jan-1970 serves fine as the "distant past" for my purposes).His answer also suggests a good programming practice about initialization of date-related variables (i.e., January 2nd, not the 1st). Mike
So it's not .net? And that's a work-around, not a fix. I think I'll try to get C# to do something like that. This might be a new kind of Friday quiz -- write a method that causes exception X. -- modified at 10:01 Saturday 10th February, 2007
-
So it's not .net? And that's a work-around, not a fix. I think I'll try to get C# to do something like that. This might be a new kind of Friday quiz -- write a method that causes exception X. -- modified at 10:01 Saturday 10th February, 2007
I have no idea what you're talking about, but good luck with that.
-
This one's not mine. I came across it at http://www.experts-exchange.com/Operating_Systems/WinXP/Q_22150503.html[^], but it seems to fit the "subtle bugs" category and I wanted to share it here. The developer had an internationally-deployed application which, apparently after a version upgrade, began to fail reliably with the message "The application has requested the Runtime to terminate it in an unusual way." However, the failure occurred only in Europe; the failure was not reproducible in the US. He tried linking with the "/MAP" linker option, and changing his WinMain code to install an exception handler that would allow him to see where the failure occurred. However, the failure was occurring before any of his code was executed, so it was failing even before the exception handler could be installed. After a false lead involving a possible flaw in the Microsoft assert() code, he eventually traced the problem to an initialization of a static variable (which of course is initialized by the CRT before any of his code is executed). Here is the developer's explanation of the problem and his solution:
A Smart Developer wrote:
What it turned out to be was the initialization of a static variable to what amounted to a negative time for anyone east of Greenwich:
static CTime distantPast = CTime(1970, 1, 1, 0, 0, 0);Once I set my time zone to Berlin, the debugger found the problem in about 5 sec. The fix was very simple (2-Jan-1970 serves fine as the "distant past" for my purposes).His answer also suggests a good programming practice about initialization of date-related variables (i.e., January 2nd, not the 1st). Mike
Seems a bit wierd to me. The C runtime code includes error handling code such as:
return (time_t)(-1);so clearly negative values relative to the epoch are expected. -
This one's not mine. I came across it at http://www.experts-exchange.com/Operating_Systems/WinXP/Q_22150503.html[^], but it seems to fit the "subtle bugs" category and I wanted to share it here. The developer had an internationally-deployed application which, apparently after a version upgrade, began to fail reliably with the message "The application has requested the Runtime to terminate it in an unusual way." However, the failure occurred only in Europe; the failure was not reproducible in the US. He tried linking with the "/MAP" linker option, and changing his WinMain code to install an exception handler that would allow him to see where the failure occurred. However, the failure was occurring before any of his code was executed, so it was failing even before the exception handler could be installed. After a false lead involving a possible flaw in the Microsoft assert() code, he eventually traced the problem to an initialization of a static variable (which of course is initialized by the CRT before any of his code is executed). Here is the developer's explanation of the problem and his solution:
A Smart Developer wrote:
What it turned out to be was the initialization of a static variable to what amounted to a negative time for anyone east of Greenwich:
static CTime distantPast = CTime(1970, 1, 1, 0, 0, 0);Once I set my time zone to Berlin, the debugger found the problem in about 5 sec. The fix was very simple (2-Jan-1970 serves fine as the "distant past" for my purposes).His answer also suggests a good programming practice about initialization of date-related variables (i.e., January 2nd, not the 1st). Mike
Small corretion, please. The problem was really in MS code for
assert(). This assert() was not initialized correctly, and tried to use an unexistingstderr. Therefore, instead of displaying an assertion message, the application aborted with "Terminated in an unusual way". The problem was that the static variable initialization happened before he could use the patch suggested by Microsoft. Therefore the only way to fix it all was to find and cure the origin of assertion. -
Small corretion, please. The problem was really in MS code for
assert(). This assert() was not initialized correctly, and tried to use an unexistingstderr. Therefore, instead of displaying an assertion message, the application aborted with "Terminated in an unusual way". The problem was that the static variable initialization happened before he could use the patch suggested by Microsoft. Therefore the only way to fix it all was to find and cure the origin of assertion.Still just a work-around, right?
-
Still just a work-around, right?
So?
-------- Micrologic Networks, India