Re: VerQueryValue Bug?
- From: "Alexander Grigoriev" <alegr@xxxxxxxxxxxxx>
- Date: Thu, 28 Apr 2005 20:07:07 -0700
The heap corruption might have been happened in other cases, but heap check
is only performed when the application runs under debugger.
You need to find the exact cause of the problem, not just settle when some
unrelated changes seem to make the problem disappear.
Make sure you didn't write 'new BYTE(size)'.
"Rob Smitter" <rsmitter@xxxxxxxxxxxx> wrote in message
news:eSvC4sBTFHA.544@xxxxxxxxxxxxxxxxxxxxxxx
> Interesting result - When I changed the code that allocated the allocated
> the buffer for the resouce block from a
>
> Buf = new BYTE[size] followed by a delete []Buf
>
> to a malloc and a free, the debug exception issue went away
>
> There were other things that I needed to change in the actual code (non
> test
> case) other code also related to using wstring variables declared local to
> the function that verqueryvalue was called from. When they were going out
> of scope, and onl;y in the debugger the same thing would happen. And if
> the
> call to verqueryvalue was not called there was not problem.
>
> I believe that debug and verqueryvalue can have unexpected side effects.
> I
> have used it many times and only under these circumstances has this
> happened.
>
>
>
> "Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> wrote in message
> news:%23$NFtz$SFHA.2880@xxxxxxxxxxxxxxxxxxxxxxx
>> The heap check is only performed when yuou run under debugger.
>>
>> You may need to post a larger piece of code.
>>
>> "Rob Smitter" <rsmitter@xxxxxxxxxxxx> wrote in message
>> news:%23bLl4O$SFHA.2256@xxxxxxxxxxxxxxxxxxxxxxx
>> > That is not the issue. The test I made was not even using the result.
> To
>> > test out what was happening it did just:
>> >
>> > Allocated a buffer
>> > Copy the resource block into the buffer
>> > Call VerQueryValue
>> > delete the buffer - exception gets called
>> >
>> > Only in debug mode when stepping through the code
>> >
>> > The result, pstrResult, did have the correct data in it. It was never
>> > used,
>> > never saved. The issue is that it seems VerQueryValue has either a bug
> in
>> > debug mode or the debug memory free has a problem.
>> >
>> >
>> > "Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> wrote in message
>> > news:OqJy$05SFHA.3840@xxxxxxxxxxxxxxxxxxxxxxx
>> >> You should NOT be using whavever returned in pstrResult after you free
>> > 'p'.
>> >>
>> >> "Rob Smitter" <rsmitter@xxxxxxxxxxxx> wrote in message
>> >> news:%23sUOkg4SFHA.3936@xxxxxxxxxxxxxxxxxxxxxxx
>> >> > Is there any known problem with VerQueryValue.
>> >> >
>> >> > An example of how I am using it is:
>> >> >
>> >> > wchar_t* pstrResult = NULL;
>> >> > unsigned int VersionLength = 0;
>> >> >
>> >> > if (VerQueryValue(p, L"\\StringFileInfo\\040904e4\\FileVersion",
>> >> > pstrInfoName", (void **)&pstrResult, (unsigned int
>> >> > *)&VersionLength))
> {
>> >> > ...
>> >> > }
>> >> >
>> >> > where p is a pointer to the resource.
>> >> >
>> >> > As a side note, we do not use GetFileVersionInfo to get P but
>> >> > derive
>> > it.
>> >> > on
>> >> > our own and allocate it.
>> >> >
>> >> > The symptom is this -
>> >> >
>> >> > If we make the call to VerQueryValue and then delete p, and only in
>> > debug
>> >> > mode, we get a runtime error
>> >> >
>> >> > HEAP[Test.exe]: HEAP: Free Heap block 8a34a8 modified at 8a3624
>> >> > after
>> >> > it
>> >> > was
>> >> > freed
>> >> > Unhandled exception at 0x77f75a58 in Test.exe: User breakpoint
>> >> >
>> >> > If we skip the call to VerQueryVal\lue and delete it all is well.
>> >> > It
>> >> > seems
>> >> > VerQueryValue has an effect on the memory in debug mode
>> >> >
>> >> > In (we are compiling multithreaded debug)
>> >> >
>> >> > _CRTIMP void __cdecl _free_dbg(
>> >> >
>> >> > at these lines:
>> >> >
>> >> > /* fill the entire block including header with dead-land-fill */
>> >> > memset(pHead, _bDeadLandFill, sizeof(_CrtMemBlockHeader) +
>> >> > pHead->nDataSize
>> >> > + nNoMansLandSize);
>> >> > _free_base(pHead);
>> >> >
>> >> > When _free_base(pHead) is called it calls
>> >> >
>> >> > HeapFree(_crtheap, 0, pBlock);
>> >> >
>> >> > Then we get the errors mentioned above.
>> >> >
>> >> > Any information on if there is known issue would be most
>> >> > appreciated.
>> >> > Again, the point is that the call to VerQueryValue is the only thing
>> > that
>> >> > gets done and the problem appears. I have even copied the version
>> >> > block
>> >> > into another buffer I allocated just before the call and did a
>> >> > delete
>> >> > after
>> >> > and it causes the problem. By copying to a stack variable I made
> large
>> >> > enough to handle the data all seemed fine.
>> >> >
>> >> > Another note - no problem when running in debug mode using start
>> >> > without
>> >> > debugging. Only when doing a normal start. VC 7 Visual C++.net
>> >> >
>> >> > Thanks much for any help.
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
.
- References:
- VerQueryValue Bug?
- From: Rob Smitter
- Re: VerQueryValue Bug?
- From: Alexander Grigoriev
- Re: VerQueryValue Bug?
- From: Rob Smitter
- Re: VerQueryValue Bug?
- From: Alexander Grigoriev
- Re: VerQueryValue Bug?
- From: Rob Smitter
- VerQueryValue Bug?
- Prev by Date: Re: Enable or disable devices
- Next by Date: Re: How to format a volume
- Previous by thread: Re: VerQueryValue Bug?
- Next by thread: Catching access violations.
- Index(es):
Relevant Pages
|
Loading
