Unaddr error from v8 generated code to be investigated #1582
Comments
|
From [email protected] on June 26, 2014 14:35:33 This could be reproduced locally: .\tools\valgrind\chrome_tests.bat -b out\Release -t browser_tests --tool drmemory_full --gtest_filter=UnloadTest.CrossSiteInfiniteBeforeUnloadAsync [----------] Global test environment tear-down |
|
From [email protected] on June 26, 2014 14:46:40 The corresponding asm: It is clear that ebp is not frame pointer. 0:000> dd 0021e86c 0:000> dd 0021e8a8 0:000> dd 0021e900 except the 0021e84c is a little bit off off, the rest looks like a linked list. |
|
From [email protected] on June 26, 2014 15:06:25 Similar errors at http://build.chromium.org/p/chromium.fyi/builders/Windows%20Browser%20%28DrMemory%20full%29%20%2812%29/builds/222 UnloadTest.CrossSiteInfiniteBeforeUnloadSync |
|
From [email protected] on June 27, 2014 02:25:25
How so? ebp is very much the frame pointer. Its value is 0021e848, where you can see the address of the next frame (0021e86c). So the apparent "linked list" is in fact the stack, with each stack frame pointing to the next. Note that the access that DrM complains about is [ebp-0xc], not [ebp]. The C++ code that generated this asm code is LCodeGen::GenerateOsrPrologue, see https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/ia32/lithium-codegen-ia32.cc#352 . It hasn't changed in 9 months, for whatever that's worth. What this code does is it moves the entire stack frame by one pointer in the direction of lower addresses in order to 8-byte align it. The 0x12345678 you see at address 0021e858 is the filler value that was put in. Does DrM make any assumptions that stack frames never move? I don't see what the bug/problem is here. Doesn't the fact that "dd 0x0021e83c" has given you useful results prove that this address is perfectly addressable? I don't see why [frame pointer - 0xc] would be an invalid access. Unless we're actually three pointer sizes away from a stack overflow, but that seems unlikely. What does esp point to? If the stack frame is empty (no local variables), then it might be that esp == 0021e838. The value 0x0021e84c at address 0x0021e83c would then be a leftover frame pointer from a previous call, which seems plausible. Does DrM complain when addresses just below esp are accessed (i.e. [esp - x] for small x)? |
|
From [email protected] on June 27, 2014 08:42:11
Yes, any access beyond the top of the stack is considered unaddressable. This type of code is unsafe on 32-bit *nix and frowned upon elsewhere. |
|
From [email protected] on June 27, 2014 08:48:46 I'm not sure why this was filed in the DrMem tracker. The v8 code violates the safe programming model checked by Dr. Memory, so this seems to be a true positive correctly identified, with the tool working as designed. |
|
From [email protected] on June 27, 2014 08:54:27 xref issue #1584 |
From [email protected] on June 26, 2014 17:34:12
http://build.chromium.org/p/chromium.fyi/builders/Windows%20Browser%20%28DrMemory%20full%29%20%286%29/builds/639 =====================================================
Below is the report for drmemory wrapper PID=2356_20.
It was used while running the
UnloadTest.CrossSiteInfiniteBeforeUnloadAsynctest.Suppressions used:
count name
3 https://code.google.com/p/drmemory/issues/detail?id=18 d
3 http://crbug.com/346842 4 bug_347967_all_osmesa
4 https://code.google.com/p/drmemory/issues/detail?id=113 rpcrt4.dll wildcard
4 https://code.google.com/p/drmemory/issues/detail?id=412 h
4 https://code.google.com/p/drmemory/issues/detail?id=513 d
4 https://code.google.com/p/drmemory/issues/detail?id=748 7 http://crbug.com/346993 8 https://code.google.com/p/drmemory/issues/detail?id=512 b
13 https://code.google.com/p/drmemory/issues/detail?id=412 c
21 http://crbug.com/371942 24 https://code.google.com/p/drmemory/issues/detail?id=68 a
44 http://crbug.com/371357 770 sqlite3_randomness UNINIT
09:55:40 drmemory_analyze.py [INFO] Found 1 error reports
09:55:40 drmemory_analyze.py [INFO] Report
#1UNADDRESSABLE ACCESS: reading 0x002ee964-0x002ee968 4 byte(s)
#0 (0x3eb4f2fa)
#1 v8.dll!v8::internal::Invoke [v8\src\execution.cc:94]
#2 v8.dll!v8::internal::Execution::Call [v8\src\execution.cc:149]
#3 v8.dll!v8::Function::Call [v8\src\api.cc:4002]
#4 blink_web.dll!WebCore::V8ScriptRunner::callFunction [third_party\webkit\source\bindings\v8\v8scriptrunner.cpp:140]
#5 blink_web.dll!WebCore::ScriptController::callFunction [third_party\webkit\source\bindings\v8\scriptcontroller.cpp:162]
#6 blink_web.dll!WebCore::ScriptController::callFunction [third_party\webkit\source\bindings\v8\scriptcontroller.cpp:145]
#7 blink_web.dll!WebCore::V8EventListener::callListenerFunction [third_party\webkit\source\bindings\v8\v8eventlistener.cpp:88]
#8 blink_web.dll!WebCore::V8AbstractEventListener::invokeEventHandler [third_party\webkit\source\bindings\v8\v8abstracteventlistener.cpp:126]
#9 blink_web.dll!WebCore::V8AbstractEventListener::handleEvent [third_party\webkit\source\bindings\v8\v8abstracteventlistener.cpp:96]
#10 blink_web.dll!WebCore::EventTarget::fireEventListeners [third_party\webkit\source\core\events\eventtarget.cpp:348]
#11 blink_web.dll!WebCore::EventTarget::fireEventListeners [third_party\webkit\source\core\events\eventtarget.cpp:284]
#12 blink_web.dll!WebCore::LocalDOMWindow::dispatchEvent [third_party\webkit\source\core\frame\localdomwindow.cpp:1634]
#13 blink_web.dll!WebCore::Document::dispatchBeforeUnloadEvent [third_party\webkit\source\core\dom\document.cpp:2610]
#14 blink_web.dll!WebCore::FrameLoader::shouldClose [third_party\webkit\source\core\loader\frameloader.cpp:1275]
#15 content.dll!content::RenderFrameImpl::OnBeforeUnload [content\renderer\render_frame_impl.cc:919]
#16 content.dll!content::RenderFrameImpl::OnMessageReceived [content\renderer\render_frame_impl.cc:684]
#17 content.dll!content::MessageRouter::RouteMessage [content\common\message_router.cc:54]
Original issue: http://code.google.com/p/drmemory/issues/detail?id=1582
The text was updated successfully, but these errors were encountered: