Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

If windows date is older than current date, nvda exits with an error at start up. #3260

Closed
nvaccessAuto opened this issue Jun 2, 2013 · 3 comments

Comments

@nvaccessAuto
Copy link

Reported by briang1 on 2013-06-02 15:38
I just had to change the cmos battery in a machine with nvda on it due to it losing days and time. On rebooting the machine, the nvda set to start at startup crashed giving a critical stop in windows sound. The on disc portable version did the same. I did however find that running an installer packaged did work and allowed me to reset the date and time in order to do a reboot wherupon nvda started working again. Seems to me that somewhere along the line its attempting to read file dates and times and compare them to something that if completely silly makes the calculation overflow. The log is below.

INFO - nvda (03:17:28):
Starting NVDA
INFO - core.main (03:17:30):
Config dir: C:\Documents and Settings\brian\Application Data\nvda
DEBUG - core.main (03:17:33):
setting language to Windows
INFO - core.main (03:17:33):
NVDA version master-9257,65c071b
INFO - core.main (03:17:33):
Using Windows version sys.getwindowsversion(major=5, minor=1, build=2600,
platform=2, service_pack='Service Pack 3')
INFO - core.main (03:17:33):
Using Python version 2.7.3 (default, Apr 10 2012, 23:31:26) v.1500 32
bit (Intel)

INFO - core.main (03:17:33):
Using comtypes version 0.6.2
DEBUG - core.main (03:17:33):
Initializing addons system.
DEBUG - addonHandler.getAvailableAddonsFromPath (03:17:33):
Listing add-ons from C:\Documents and Settings\brian\Application
Data\nvda\addons
DEBUG - core.main (03:17:38):
Initializing appModule Handler
DEBUG - core.main (03:17:38):
Initializing NVDAHelper
DEBUG - core.main (03:17:38):
Speech Dictionary processing
DEBUG - speechDictHandler.SpeechDict.load (03:17:38):
Loading speech dictionary 'C:\Documents and Settings\brian\Application
Data\nvda\speechDicts\default.dic'...
DEBUG - speechDictHandler.SpeechDict.load (03:17:38):
10 loaded records.
DEBUG - speechDictHandler.SpeechDict.load (03:17:38):
Loading speech dictionary 'builtin.dic'...
DEBUG - speechDictHandler.SpeechDict.load (03:17:38):
3 loaded records.
DEBUG - core.main (03:17:38):
Initializing speech
INFO - synthDrivers.espeak.SynthDriver.init (03:17:39):
Using eSpeak version 1.47.11 03.May.13
DEBUG - speechDictHandler.SpeechDict.load (03:17:42):
Loading speech dictionary 'C:\Documents and Settings\brian\Application
Data\nvda\speechDicts\espeak-english.dic'...
DEBUG - speechDictHandler.SpeechDict.load (03:17:42):
1 loaded records.
INFO - synthDriverHandler.setSynth (03:17:42):
Loaded synthDriver espeak
DEBUGWARNING - core.main (03:17:42):
Slow starting core (13.67 sec)
IO - speech.speak (03:17:42):
Speaking ('en_GB'), u'Loading NVDA. Please wait...'
INFO - core.main (03:17:42):
Using wx version 2.8.12.1 (msw-unicode)
DEBUG - core.main (03:17:42):
Initializing braille
INFO - braille.initialize (03:17:42):
Using liblouis version 2.5.2
INFO - braille.BrailleHandler.setDisplayByName (03:17:42):
Loaded braille display driver noBraille, current display has 0 cells.
DEBUG - core.main (03:17:42):
Initializing braille input
INFO - brailleInput.initialize (03:17:42):
Braille input initialized
DEBUG - core.main (03:17:42):
Initializing displayModel
DEBUG - core.main (03:17:42):
Initializing GUI
DEBUG - core.main (03:17:42):
initializing Java Access Bridge support
DEBUG - core.main (03:17:42):
Initializing winConsole support
DEBUG - core.main (03:17:42):
Initializing UIA support
WARNING - core.main (03:17:42):
UIA not available
DEBUG - core.main (03:17:42):
Initializing IAccessible support
DEBUG - core.main (03:17:42):
Initializing input core
DEBUGWARNING - inputCore.InputManager.loadLocaleGestureMap (03:17:42):
No locale gesture map for language en
DEBUGWARNING - inputCore.InputManager.loadUserGestureMap (03:17:42):
No user gesture map
DEBUG - core.main (03:17:42):
Initializing keyboard handler
DEBUG - core.main (03:17:42):
initializing mouse handler
DEBUG - core.main (03:17:42):
Initializing touchHandler
DEBUGWARNING - touchHandler.initialize (03:17:42):
Touch only supported on Windows 8 and higher
DEBUG - core.main (03:17:42):
Initializing global plugin handler
DEBUG - core.main (03:17:42):
starting core pump
DEBUG - core.CorePump.init (03:17:42):
Core pump starting
DEBUG - core.main (03:17:42):
Initializing watchdog
DEBUG - core.main (03:17:42):
initializing updateCheck
DEBUGWARNING - watchdog.watcher (03:17:43):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 159, in
File "logging__init
.pyc", line 1184, in critical
File "logHandler.pyc", line 131, in log
File "logging__init
_.pyc", line 1258, in log
File "logging__init
_.pyc", line 1268, in handle
File "logging__init__.pyc", line 1308, in callHandlers
File "logHandler.pyc", line 215, in handle

CRITICAL - nvda (03:17:42):
core failure
Traceback (most recent call last):
File "nvda.pyw", line 157, in
File "core.pyc", line 303, in main
File "updateCheck.pyc", line 447, in initialize
File "updateCheck.pyc", line 147, in init
File "wx_misc.pyc", line 1315, in Start
OverflowError: Python int too large to convert to C long
WARNING - watchdog._watcher (03:17:58):
Core frozen in stack:
File "threading.pyc", line 780, in _exitfunc
File "threading.pyc", line 663, in join
File "threading.pyc", line 243, in wait

Obviously this issue is going to occur rarely, but if anyone does want to put their clock back then at present beware.

Blocking #3458

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2013-06-03 00:20
Changes:
Milestone changed from None to 2013.2

@nvaccessAuto
Copy link
Author

Comment 3 by James Teh <jamie@... on 2013-06-03 06:32
In [c50b8f2]:

NVDA no longer fails to start if the system time is earlier than the last check for an update.

When this happens (e.g. to a CMOS battery change), the time since the last check could be a very large negative number, which in turn becomes a large positive number when calculating the time to the next check. If it's large enough, this will cause an overflow.
Therefore, restrict the time since the last check so it can never be earlier than now (must be >= 0).
Fixes #3260.

Changes:
State: closed

@nvaccessAuto
Copy link
Author

Comment 4 by briang1 on 2013-06-03 07:24
In my case it was 1st January 2002!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants