caused by some logic errors in memmove_s and memcpy_s. Fixed in revision 109
Revision 109 did not fix the issue for me. Actually it changed so much in
mi_exe_stub/build.scons that this may be a new issue, but it has the same
symptoms for me with an optimized build on VS2008.
I can run and debug the optimized mi_exe_stub.exe (of course it quits early
as it doesn't contain the tarball). However the tagged
GoogleUpdateSetup.exe crashes with an access violation. ("First-chance
exception at 0x76619eff in OmahaDemoSetup.exe: 0xC0000005: Access violation
reading location 0x00000250. The instruction at 0000000077B71221 tried to
read from an invalid address, 0000000000000250.
Unhandled exception at 0x76619eff in OmahaDemoSetup.exe: 0xC000041D: An
unhandled exception was encountered during a user callback.")
Furthermore there was a spurious reference to the msvcr90.dll runtime.
To fix the issue I made the following changes:
1) Removed the reference to $WDK_PATH. This was necessary to get the
optimized build to build at all.
- if not temp_env.Bit('debug'):
- # Stubs for W2k compatibility.
- exe_inputs += '$WDK_PATH/lib/w2k/i386/msvcrt_win2000.obj',
+ #if not temp_env.Bit('debug'):
+ # # Stubs for W2k compatibility.
+ # exe_inputs += '$WDK_PATH/lib/w2k/i386/msvcrt_win2000.obj',
2) Linked to the static runtime lib to match the /MT switch.
- ('msvcrt', 'libcmtd')[temp_env.Bit('debug')],
- ('msvcprt', 'libcpmtd')[temp_env.Bit('debug')],
+ ('libcmt', 'libcmtd')[temp_env.Bit('debug')],
+ ('libcpmt', 'libcpmtd')[temp_env.Bit('debug')],
Hope this helps someone.
Comment #3 on issue 19 by ryan...@google.com: memory bug in
mi_exe_stub/minicrt
http://code.google.com/p/omaha/issues/detail?id=19
(No comment was entered for this change.)