Re: Unusual (to me) local variable corruption problem



I would suspect calling convention mismatch or number (or size) of arguments
mismatch.
Are those OLE functions of some COM objects, or just system COM functions?
Do you have #pragma pack anywhere in your code?

"JT" <NgPoster@xxxxxxxxxxx> wrote in message
news:fc1pk2lnpmhdut2ss6ggmmu9k0liv86gbn@xxxxxxxxxx
As I noted, the problem does not exhibit after a debug build. I don't
think asking the debugger to watch the location would particularly
help in any case since afaik it does not do so on an instruction by
instruction basis, and I already know "well enough" where it occurs -
a call to a function about 10 lines long that calls a couple of OLE
functions. I haven't tried to isolate further because that last
function isn't related to the problem variable and shouldn't touch
memory anywhere near it, except for another int on the stack near the
problem, but which I'm pretty sure I've cleared of guilt.

I could step through that last function but to actually see where the
problem occurs I'd end up doing it at the asm level where a couple of
innocent calls to OLE API's will turn into pages of code. So I was
hoping to piggyback on someone's previous experience with a similar
problem.

[Actually there's something scary going on with the OLE libraries - my
first problem came when I handed a release version of the "thoroughly
debugged" program to my user and it wouldn't even open a spreadsheet
for him. It launched Excel but the command to open a workbook failed.
I beat on that for a while and "fixed" that problem by telling the
compiler to use "default" optimization rather than "best speed" which
had been the choice. I think I have the latest libraries fwiw.]


"William DePalo [MVP VC++]" <willd.no.spam@xxxxxxxx> wrote:

"JT" <NgPoster@xxxxxxxxxxx> wrote in message
news:9b8ok2pun974m3vjrbnj7897mj64arg57p@xxxxxxxxxx
I have a fairly prosaic Win32 GUI app that corrupts an int local to
one of my functions. Changing the position of the int on the
function's stack "solves" the problem, as if I'm writing something to
the wrong location, but a dummy variable placed in that location does
not suffer the same fate. Nor does placing large dummy arrays on
either side of the problem variable (which of course dramatically
changes its location relative to its active neighbors) isolate the
problem variable from its unknown assailant.
...
Thoughts?

Have you tried setting a "data breakpoint" so that the debugger notifies
you
when the integer's value changes?

http://windowssdk.msdn.microsoft.com/en-us/library/350dyxd0.aspx

Regards,
Will




.



Relevant Pages

  • Re: Unusual (to me) local variable corruption problem
    ... a call to a function about 10 lines long that calls a couple of OLE ... except for another int on the stack near the ... [Actually there's something scary going on with the OLE libraries - my ... Have you tried setting a "data breakpoint" so that the debugger notifies you ...
    (microsoft.public.vc.language)
  • Update your OLE?
    ... I am trying use mscorlib.dll from old VC6 MFC app that was ported to the VC7 ... "OLE initialization failed. ... Make sure that the OLE libraries are the correct ... This User Action doesn't help much. ...
    (microsoft.public.vc.mfc)
  • Update your OLE?
    ... I am trying use mscorlib.dll from old VC6 MFC app that was ported to the VC7 ... "OLE initialization failed. ... Make sure that the OLE libraries are the correct ... This User Action doesn't help much. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: About Post "It actually happened!"
    ... The debugger in D7 is crap. ... Ole ... Prev by Date: ...
    (borland.public.delphi.non-technical)
  • Re: MFC ActiveX control error
    ... "OLE initilization Failed.Make sure that the OLE libraries are correct ... I havent seen this failure before. ...
    (microsoft.public.vc.mfc)