False reports when using Clipboard

[derekbruening]

From timurrrr@google.com on September 03, 2010 11:24:12

as of r42 , the following code gives false uninit reports:
===test.cpp===
#include <windows.h>

#include <assert.h>
#include <stdio.h>
#include <winuser.h>
#pragma comment(lib, "user32.lib")

#include

void WriteStringToClipboard(const std::string& str) {
HWND hWnd = ::GetDesktopWindow();
assert(::OpenClipboard(hWnd));
::EmptyClipboard();
HGLOBAL data = ::GlobalAlloc(2 /GMEM_MOVABLE/, str.size() + 1);
assert(data != NULL);

char* raw_data = (char*)::GlobalLock(data);
memcpy(raw_data, str.data(), str.size() * sizeof(char));
raw_data[str.size()] = '\0';
::GlobalUnlock(data);

assert(::SetClipboardData(CF_TEXT, data));
::CloseClipboard();
}

void ReadAsciiStringFromClipboard(std::string *result) {
assert(result != NULL);

HWND hWnd = ::GetDesktopWindow();
assert(::OpenClipboard(hWnd));

HANDLE data = ::GetClipboardData(CF_TEXT);
assert(data != NULL);

result->assign((const char*)::GlobalLock(data));

::GlobalUnlock(data);
::CloseClipboard();
}

int main() {
std::string tmp, str = "ASCII";
WriteStringToClipboard(str);
ReadAsciiStringFromClipboard(&tmp);
assert(strcmp(tmp.c_str(), "ASCII") == 0);
return 0;
}

cl /EHsc /Zi /nologo test.cpp
drmemory.exe test.exe

The first stack is: Error `#1`: UNINITIALIZED READ: reading register edx @0:00:01.640 in thread 3428 0x100df1f0 drmemorylib.dll!replace_strlen z:\drmemory\git_svn\drmemory\replace.c:211 0x0040157c test.exe!std::char_traits::length c:\program files\microsoft visual studio 8\vc\include\iosfwd:442 0x00401550 test.exe!std::basic_string,std::allocator >::assign c:\program files\microsoft visual studio 8\vc\include\xstring:1070 0x00401313 test.exe!ReadAsciiStringFromClipboard z:\dr-sandbox\issues\clipboard\test.cpp:35 0x0040138d test.exe!main z:\dr-sandbox\issues\clipboard\test.cpp:44

and the following look related.

Attachment: 45.txt

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

[derekbruening]

From timurrrr@google.com on May 03, 2011 06:02:22

Update: as of r273 , it still reports the uninit read and looks like it thinks the '\0' is uninitialized:
UNINITIALIZED READ: reading 0x00154945-0x00154946 1 byte(s)
while
::GlobalLock returns 0x00154940 -> "ASCII\0"

[derekbruening]

From timurrrr@google.com on May 03, 2011 06:04:22

... and ::GlobalSize() returns 6

[derekbruening]

From timurrrr@google.com on May 03, 2011 06:30:22

(on XP 32-bit)
::OpenClipboard results in WARNING: unhandled system call #0x11d5
::EmptyClipboard results in WARNING: unhandled system call #0x116d
::SetClipboardData results in WARNING: unhandled system call #0x114f WARNING: unhandled system call #0x11fc
::CloseClipboard results in WARNING: unhandled system call #0x11fc WARNING: unhandled system call #0x114b
::GetClipboardData -> WARNING: unhandled system call #0x1185 WARNING: unhandled system call #0x1156 WARNING: unhandled system call #0x1156

These guys look like win32k system calls http://www.woodmann.com/forum/archive/index.php/t-10295.html 114b: bf8f85a7 NtUserCloseClipboard 0
114f: bf8ea924 NtUserConvertMemHandle 2
1156: bf8f9a46 NtUserCreateLocalMemHandle 4
116d: bf8ea5a9 NtUserEmptyClipboard 0
1185: bf8f9881 NtUserGetClipboardData 2
11d5: bf8f8524 NtUserOpenClipboard 2
11fc: bf8ea848 NtUserSetClipboardData 3

Looks like we're not handling some of these correctly (off-by-one error?)

Derek, can you please take a look?

From drmemory\syscall_windows.c:
/* FIXME PR 406349: win32k.sys syscalls! currently doing memcmp to see what was written
-> could it be that GlobalLock writes all 6 bytes but the last \0 byte was already \0 and memcmp have not seen this?

Owner: bruen...@google.com
Cc: -derek.br...@gmail.com

[derekbruening]

From bruen...@google.com on May 03, 2011 07:09:25

I turned off -syscall_sentinels b/c it's risky. As an experiment try turning it on and these may go away b/c drmem will see the 0 being written.

I am in the process of adding handling for non-ntdll syscall wrappers, once done w/ ioctls.

[derekbruening]

From derek.br...@gmail.com on July 15, 2011 13:02:39

This issue was closed by revision r397 .

Status: Fixed