memory bug in mi_exe_stub/minicrt

[GoogleCodeExporter]

What steps will reproduce the problem?
1. compile mi_exe_stub with VS2008
2. create a tagged metainstaller
3. run the tagged metainstaller, nothing happens

What is the expected output? What do you see instead?
installer downloaded and run. Nothing is shown instead, the metainstaller 
process quits.

What version of the product are you using? On what operating system?
trunk. Windows7,VS2008

Please provide any additional information below.
I tried to debug it... it seemed that after assigning a string to 
target_directory_name_ in tar.cc, the memory was corrupt. If I linked to 
libcmt.lib,libcpmt.lib instead of minicrt.lib everything worked.
Adding this code to the Tar constructor and linking with minicrt results in 
a blank message being displayed:
CString foo = _T("bar");
MessageBox(0, foo, _T(""), MB_OK);

sorry I haven't been able to figure out the exact problem in minicrt.

Original issue reported on code.google.com by bevan.co...@gmail.com on 27 Apr 2010 at 3:03

[GoogleCodeExporter]

caused by some logic errors in memmove_s and memcpy_s. Fixed in revision 109

Original comment by bevan.co...@gmail.com on 6 Sep 2011 at 11:27

[GoogleCodeExporter]

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.

Original comment by ben.chal...@red-gate.com on 10 Jan 2012 at 11:01

[GoogleCodeExporter]

Original comment by ryanmyers@google.com on 16 Mar 2012 at 7:30

• Changed state: Fixed