DynamoRIO / DynamoRIO/drmemory
INVALID HEAP ARGUMENT: allocated with operator new, freed with operator delete[] for chrome release build
- Dominant language
- C
- Stars
- 2.7k
- Forks
- 290
- PR merge metrics
- No merged PRs in 30d
Description
_From [zhao...@google.com](https://code.google.com/u/106321947286816917100/) on October 22, 2012 17:44:34_
xref https://code.google.com/p/chromium/issues/detail?id=156900 When build chromium with optimization /O2 /Ob1, many errors reported as:
"NVALID HEAP ARGUMENT: allocated with operator new, freed with operator delete[]"
For example:
$ ~/Workspace/DrMemory/builds/build_x86_dbg.git/bin/drmemory.exe -pattern 0xf1fd -no_count_leaks -- ./net_unittests.exe --gtest_filter=ProxyResolverV8Test.Direct
Note: Google Test filter = ProxyResolverV8Test.Direct
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from ProxyResolverV8Test
[ RUN ] ProxyResolverV8Test.Direct
~~Dr.M~~
~~Dr.M~~ Error `#1`: INVALID HEAP ARGUMENT: allocated with operator new, freed with operator delete[]
~~Dr.M~~ # 0 v8.dll!v8::internal::Parser::~Parser [d:\src\chrome-int\src\v8\src\parser.h:438]
~~Dr.M~~ # 1 v8.dll!v8::internal::ParserApi::Parse [d:\src\chrome-int\src\v8\src\parser.cc:5967]
~~Dr.M~~ # 2 v8.dll!v8::internal::Compiler::CompileLazy [d:\src\chrome-int\src\v8\src\compiler.cc:803]
~~Dr.M~~ # 3 v8.dll!v8::internal::JSFunction::CompileLazy [d:\src\chrome-int\src\v8\src\objects.cc:7692]
~~Dr.M~~ # 4 v8.dll!v8::internal::Runtime_LazyCompile [d:\src\chrome-int\src\v8\src\runtime.cc:7878]
~~Dr.M~~ # 5 v8.dll!v8::internal::Invoke [d:\src\chrome-int\src\v8\src\execution.cc:118]
~~Dr.M~~ # 6 v8.dll!v8::internal::Execution::Call [d:\src\chrome-int\src\v8\src\execution.cc:179]
~~Dr.M~~ # 7 v8.dll!v8::internal::Execution::InstantiateFunction [d:\src\chrome-int\src\v8\src\execution.cc:738]
~~Dr.M~~ # 8 v8.dll!v8::internal::Execution::InstantiateObject [d:\src\chrome-int\src\v8\src\execution.cc:756]
~~Dr.M~~ # 9 v8.dll!v8::internal::Genesis::ConfigureGlobalObjects [d:\src\chrome-int\src\v8\src\bootstrapper.cc:2154]
~~Dr.M~~ `#10` v8.dll!v8::internal::Genesis::Genesis [d:\src\chrome-int\src\v8\src\bootstrapper.cc:2351]
~~Dr.M~~ `#11` v8.dll!v8::internal::Bootstrapper::CreateEnvironment [d:\src\chrome-int\src\v8\src\bootstrapper.cc:307]
~~Dr.M~~ Note: @0:00:57.340 in thread 15068
However, this might be the result of optimizations:
On allocation, it should use new[], but be optimized calling to new instead.
ExpandBuffer at d:\src\chrome-int\src\v8\src\scanner.h
235 void ExpandBuffer() {
236 Vector new_store = Vector::New(NewCapacity(kInitialCapacity));
237 memcpy(new_store.start(), backing_store_.start(), position_);
238 backing_store_.Dispose();
239 backing_store_ = new_store;
240 }
v8\src\utils.h
static Vector New(int length) {
return Vector(NewArray(length), length);
}
void Dispose() {
DeleteArray(start_);
start_ = NULL;
length_ = 0;
}
v8\src\allocation.h
template
T\* NewArray(size_t size) {
T\* result = new T[size];
if (result == NULL) Malloced::FatalProcessOutOfMemory();
return result;
}
template
void DeleteArray(T\* array) {
delete[] array;
}
0:000> Uf eip
v8!v8::internal::LiteralBuffer::ExpandBuffer+0x8 [d:\src\chrome-int\src\v8\src\scanner.h @ 236]:
236 5c97ed88 83f810 cmp eax,0x10
236 5c97ed8b 7f05 jg v8!v8::internal::LiteralBuffer::ExpandBuffer+0x12 (5c97ed92)
v8!v8::internal::LiteralBuffer::ExpandBuffer+0xd [d:\src\chrome-int\src\v8\src\scanner.h @ 236]:
236 5c97ed8d b810000000 mov eax,0x10
v8!v8::internal::LiteralBuffer::ExpandBuffer+0x12 [d:\src\chrome-int\src\v8\src\scanner.h @ 236]:
236 5c97ed92 8d8800001000 lea ecx,[eax+0x100000]
236 5c97ed98 8d1c8500000000 lea ebx,[00000000+eax*4]
236 5c97ed9f 3bd9 cmp ebx,ecx
236 5c97eda1 7c02 jl v8!v8::internal::LiteralBuffer::ExpandBuffer+0x25 (5c97eda5)
v8!v8::internal::LiteralBuffer::ExpandBuffer+0x23 [d:\src\chrome-int\src\v8\src\scanner.h @ 236]:
236 5c97eda3 8bd9 mov ebx,ecx
v8!v8::internal::LiteralBuffer::ExpandBuffer+0x25 [d:\src\chrome-int\src\v8\src\scanner.h @ 236]:
236 5c97eda5 53 push ebx
236 5c97eda6 e8e15e0700 call v8!operator new (5c9f4c8c)
236 5c97edab 8bf8 mov edi,eax
236 5c97edad 83c404 add esp,0x4
236 5c97edb0 85ff test edi,edi
236 5c97edb2 7505 jnz v8!v8::internal::LiteralBuffer::ExpandBuffer+0x39 (5c97edb9)
While on delete, it still calls to delete[].
435 virtual ~Parser() {
436 delete reusable_preparser_;
437 reusable_preparser_ = NULL;
438 }
5cb5917c 897e70 mov [esi+0x70],edi
5cb5917f 397e38 cmp [esi+0x38],edi
5cb59182 7e12 jle v8!v8::internal::Parser::~Parser+0x36 (5cb59196)
5cb59184 8b4634 mov eax,[esi+0x34] ds:002b:003aeec4=00b43590
5cb59187 50 push eax
5cb59188 e81bbb1800 call v8!operator delete[](5cce4ca8)
More details at crbug.com/156900
_Original issue: http://code.google.com/p/drmemory/issues/detail?id=1058_
Contributor guide
Assessment
This issue has not been assessed yet.