tons of heap mismatches on libreoffice with -replace_malloc

[derekbruening]

From bruen...@google.com on May 14, 2013 17:07:15

ERRORS FOUND:
204 unique, 6405 total unaddressable access(es)
326 unique, 4648 total uninitialized access(es)
5800 unique, 40029 total invalid heap argument(s)
14 unique, 34 total GDI usage error(s)
0 unique, 0 total warning(s)
77 unique, 626 total, 49942 byte(s) of leak(s)
19 unique, 59 total, 87598 byte(s) of possible leak(s)

wrapping had 0 invalid heap args.

% grep INVALID logs/DrMemory-soffice.bin.7704.000/results.txt | sed 's/Error #[0-9]*//' | sort | uniq -c
5800 : INVALID HEAP ARGUMENT: allocated with operator new, freed with operator delete[]

Error #1: INVALID HEAP ARGUMENT: allocated with operator new, freed with operator delete[]
#0 replace_operator_delete_array [d:\derek\drmemory\git\src\common\alloc_replace.c:2422]
#1 sal3.dll!osl_setEnvironment +0xd1 (0x71d1068b <sal3.dll+0x2068b>)
#2 tllo.dll!tools::extendApplicationEnvironment +0x1a6 (0x6d2b4b58 <tllo.dll+0x34b58>)
#3 sofficeapp.dll!soffice_main +0x11 (0x6d8e60e1 <sofficeapp.dll+0x260e1>)
#4 soffice.bin!? +0x0 (0x0037101d <soffice.bin+0x101d>)
#5 soffice.bin!? +0x0 (0x0037103f <soffice.bin+0x103f>)
#6 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x75e633aa <KERNEL32.dll+0x133aa>)
#7 ntdll.dll!RtlInitializeExceptionChain +0x62 (0x777c9ef2 <ntdll.dll+0x39ef2>)
#8 ntdll.dll!RtlInitializeExceptionChain +0x35 (0x777c9ec5 <ntdll.dll+0x39ec5>)
Note: @0:00:01.800 in thread 8832
Note: memory was allocated here:
Note: # 0 replace_operator_new [d:\derek\drmemory\git\src\common\alloc_replace.c:2360]
Note: # 1 sal3.dll!osl_setEnvironment +0x66 (0x71d10620 <sal3.dll+0x20620>)
Note: # 2 tllo.dll!tools::extendApplicationEnvironment +0x1a6 (0x6d2b4b58 <tllo.dll+0x34b58>)
Note: # 3 sofficeapp.dll!soffice_main +0x11 (0x6d8e60e1 <sofficeapp.dll+0x260e1>)
Note: # 4 soffice.bin!? +0x0 (0x0037101d <soffice.bin+0x101d>)
Note: # 5 soffice.bin!? +0x0 (0x0037103f <soffice.bin+0x103f>)
Note: # 6 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x75e633aa <KERNEL32.dll+0x133aa>)
Note: # 7 ntdll.dll!RtlInitializeExceptionChain +0x62 (0x777c9ef2 <ntdll.dll+0x39ef2>)
Note: # 8 ntdll.dll!RtlInitializeExceptionChain +0x35 (0x777c9ec5 <ntdll.dll+0x39ec5>)

0:005> U 6f440000 + 0x2068b-5
sal3!osl_setEnvironment+0xcd:
6f460686 e82bad0000 call sal3!osl_getEthernetAddress+0xbc4 (6f46b3b6)
0:005> U 6f46b3b6
sal3!osl_getEthernetAddress+0xbc4:
6f46b3b6 ff256004476f jmp dword ptr [sal3!osl_getEthernetAddress+0x5c6e (6f470460)]
0:005> U poi(6f470460)
MSVCR100!Concurrency::details::CacheLocalScheduleGroup::operator delete:
6fc5017c 8bff mov edi,edi
6fc5017e 55 push ebp
6fc5017f 8bec mov ebp,esp
6fc50181 5d pop ebp
6fc50182 ebf0 jmp MSVCR100!operator delete (6fc50174)

0:005> x MSVCR100!operator delete
6fc5017c MSVCR100!Concurrency::details::WorkQueue::operator delete =
6fc5017c MSVCR100!Concurrency::details::FairScheduleGroup::operator delete =
6fc5017c MSVCR100!operator delete[] =
6fc5017c MSVCR100!Concurrency::details::ExternalContextBase::operator delete =
6fc5017c MSVCR100!Concurrency::details::CacheLocalScheduleGroup::operator delete =
6fc5017c MSVCR100!Concurrency::details::ThreadInternalContext::operator delete =
6fc50174 MSVCR100!operator delete =
6fc873eb MSVCR100!operator delete =
6fc5017c MSVCR100!Concurrency::details::UMSThreadInternalContext::operator delete =

so all these Concurrency deletes point to the same routine as operator delete[]

Original issue: http://code.google.com/p/drmemory/issues/detail?id=1233

[derekbruening]

From bruen...@google.com on May 16, 2013 19:32:15

Mis-diagnosis: this has nothing to do with Concurrency (though investigating that led to several bug discoveries: issue #1238 , issue #1239 , issue #1240 ).

I think that this is the corresponding source code but would want a debug
build of libreoffice to verify:

alloc in typelib_typedescription_newMIInterface():
pITD->ppAllMembers = new typelib_TypeDescriptionReference *[ pITD->nAllMembers ];

free in typelib_typedescription_destructExtendedMembers():
delete [] pITD->ppAllMembers;
declared as:
typelib_TypeDescriptionReference ** ppAllMembers;

I can repro with this code:
int **x = new int *[7];
delete [] x;

The key is build w/o syms, and then we have a reproducer:

Error #1: INVALID HEAP ARGUMENT: allocated with operator new, freed with operator delete[]

0 replace_operator_delete_array+0x0 [d:\derek\drmemory\git\src\common\alloc_replace.c:2422](0x73974ce0 <drmemorylib.dll+0x174ce0)

1 cs2bug.exe!? +0x0 (0x00b31077 <cs2bug.exe+0x1077>)

2 cs2bug.exe!? +0x0 (0x00b32c57 <cs2bug.exe+0x2c57>)

3 KERNEL32.dll!BaseThreadInitThunk+0x11 (0x75e633aa <KERNEL32.dll+0x133aa>)

4 ntdll.dll!__RtlUserThreadStart+0x26 (0x777c9ef2 <ntdll.dll+0x39ef2>)

Note: @0:00:01.653 in thread 9172
Note: memory was allocated here:
Note: # 0 replace_operator_new+0x0 [d:\derek\drmemory\git\src\common\alloc_replace.c:2360](0x73974370 <drmemorylib.dll+0x174370)
Note: # 1 cs2bug.exe!? +0x0 (0x00b3105c <cs2bug.exe+0x105c>)
Note: # 2 cs2bug.exe!? +0x0 (0x00b32c57 <cs2bug.exe+0x2c57>)
Note: # 3 KERNEL32.dll!BaseThreadInitThunk+0x11 (0x75e633aa <KERNEL32.dll+0x133aa>)
Note: # 4 ntdll.dll!__RtlUserThreadStart+0x26 (0x777c9ef2 <ntdll.dll+0x39ef2>)

The problem is that the stubs in the using module are asymmetric: new[]
just jumps to the local new stub before calling into msvcr, while delete[]
goes straight to msvcr on its own:

0:000> U 00b03286
cs2bug!operator new[] [f:\dd\vctools\crt_bld\self_x86\crt\src\newaop.cpp @ 5]:
00b03286 8bff mov edi,edi
00b03288 55 push ebp
00b03289 8bec mov ebp,esp
00b0328b 5d pop ebp
00b0328c e947010000 jmp cs2bug!operator new (00b033d8)
0:000> U 00b033d8
cs2bug!operator new:
00b033d8 ff25c8a3b000 jmp dword ptr [cs2bug!imp??2YAPAXIZ (00b0a3c8)]
0:000> U poi(00b0a3c8)
MSVCR100!operator new:
6fc5232b 8bff mov edi,edi

0:000> U 00b032f8
cs2bug!operator delete[]:
00b032f8 ff25d0a3b000 jmp dword ptr [cs2bug!imp??_VYAXPAXZ (00b0a3d0)]
0:000> U poi(00b0a3d0)
MSVCR100!Concurrency::details::CacheLocalScheduleGroup::operator delete:
6fc5017c 8bff mov edi,edi

This seems very familiar -- and in fact the original issue #123 hit this and solved it for wrapping (which is why wrapping doesn't show these errors on libreoffice).

Can we do the same thing for replacing? Since we replace the stubs on
modules that import from msvcr, we should be able to just disable
mismatches on msvcr's own operators.

[derekbruening]

From derek.br...@gmail.com on May 17, 2013 07:46:02

This issue was closed by revision r1381 .

Status: Fixed