Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UNINIT on calc in gdiplus.dll!DpRegion::FreeData: needs per-bit granularity #497

Open
derekbruening opened this issue Nov 28, 2014 · 1 comment

Comments

@derekbruening
Copy link
Contributor

From [email protected] on July 15, 2011 13:36:27

happens on win7 calc with "scientific view"

Error #3: UNINITIALIZED READ: reading 0x02fb26e4-0x02fb26e5 1 byte(s)
0x7256a60d <gdiplus.dll+0x4a60d> gdiplus.dll!DpRegion::FreeData
0x7257a7bc <gdiplus.dll+0x5a7bc> gdiplus.dll!GpGraphics::UpdateDrawBounds
0x7257ace8 <gdiplus.dll+0x5ace8> gdiplus.dll!GpGraphics::ResetState
0x7257c284 <gdiplus.dll+0x5c284> gdiplus.dll!GpGraphics::GpGraphics
0x7257c96b <gdiplus.dll+0x5c96b> gdiplus.dll!GpGraphics::GetFromGdiScreenDC
0x7257ccf0 <gdiplus.dll+0x5ccf0> gdiplus.dll!GpGraphics::GetFromHdc
0x725582e8 <gdiplus.dll+0x382e8> gdiplus.dll!GdipCreateFromHDC
0x00db82ae <calc.exe+0x82ae> calc.exe!Gdiplus::Graphics::Graphics
0x00db836a <calc.exe+0x836a> calc.exe!DrawPNGImageForStatic
0x00db8331 <calc.exe+0x8331> calc.exe!CGlowButton::DrawButtonText
0x00dbdd56 <calc.exe+0xdd56> calc.exe!CScientificKeypad::DrawItemText
0x00dbdd7f <calc.exe+0xdd7f> calc.exe!CScientificMode::SciDlgProc
0x7256a60d f6 46 04 04 test 0x04(%esi) $0x04

looks like it's reading an early (first non-vtable?) field in DpRegion:
gdiplus!DpRegion::FreeData:
7256a608 8bff mov edi,edi
7256a60a 56 push esi
7256a60b 8bf1 mov esi,ecx
7256a60d f6460404 test byte ptr [esi+0x4],0x4
0:000> dd @@(mc->esi)
02e526e0 67526431 00000001 ffc00000 ffc00000

bp gdiplus!DpRegion::DpRegion
there are 4: I did them all, and hit one:
0:000> dd ecx L4
02dd258c baadf00d baadf00d baadf00d baadf00d
0:000> ba r4 ecx+4
0:000> g
Breakpoint 4 hit
eax=02dd258c ebx=00000000 ecx=02dd258c edx=00000001 esi=02dd2588 edi=00000000
eip=725e9a01 esp=0022df64 ebp=0022df64 iopl=0 nv up ei ng nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000286
gdiplus!DpRegion::DpRegion+0xb:
725e9a01 8b4804 mov ecx,[eax+0x4] ds:002b:02dd2590=baadf009
0:000> Uf 725e99f6
gdiplus!DpRegion::DpRegion:
725e99f6 8bff mov edi,edi
725e99f8 55 push ebp
725e99f9 8bec mov ebp,esp
725e99fb 8bc1 mov eax,ecx
725e99fd 836004fb and dword ptr [eax+0x4],0xfffffffb <== ~0x4
725e9a01 8b4804 mov ecx,[eax+0x4]
725e9a04 33d2 xor edx,edx
725e9a06 895018 mov [eax+0x18],edx
725e9a09 395508 cmp [ebp+0x8],edx
725e9a0c 7521 jnz gdiplus!DpRegion::DpRegion+0x39 (725e9a2f)

gdiplus!DpRegion::DpRegion+0x18:
725e9a0e 83e1fd and ecx,0xfffffffd
725e9a11 83c901 or ecx,0x1
725e9a14 894804 mov [eax+0x4],ecx
725e9a17 b90000c0ff mov ecx,0xffc00000
725e9a1c 894808 mov [eax+0x8],ecx
725e9a1f 89480c mov [eax+0xc],ecx
725e9a22 b900004000 mov ecx,0x400000
725e9a27 894810 mov [eax+0x10],ecx
725e9a2a 894814 mov [eax+0x14],ecx
725e9a2d eb15 jmp gdiplus!DpRegion::DpRegion+0x4e (725e9a44)

gdiplus!DpRegion::DpRegion+0x39:
725e9a2f 83e1fe and ecx,0xfffffffe
725e9a32 83c902 or ecx,0x2
725e9a35 894804 mov [eax+0x4],ecx
725e9a38 895008 mov [eax+0x8],edx
725e9a3b 89500c mov [eax+0xc],edx
725e9a3e 895010 mov [eax+0x10],edx
725e9a41 895014 mov [eax+0x14],edx

gdiplus!DpRegion::DpRegion+0x4e:
725e9a44 c70031645267 mov dword ptr [eax],0x67526431
725e9a4a 89501c mov [eax+0x1c],edx
725e9a4d 5d pop ebp
725e9a4e c20400 ret 0x4

so it's doing some bit games.
like issue #492 and issue #493 I suspect this would go away w/ per-bit granularity
so planning to suppress for now.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant