comctl32: realloc or free and alloc

[Alexey Fisher]

On So, 2011-05-01 at 21:55 +0400, Nikolay Sivov wrote:
> On 5/1/2011 21:49, Alexey Fisher wrote:
> > On So, 2011-05-01 at 19:11 +0400, Nikolay Sivov wrote:
> >> On 5/1/2011 13:07, Alexey Fisher wrote:
> >>> There is a new patch in the attachment.
> >>>    BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc)
> >>>    {
> >>> -    TRACE("(%p %s)\n", lppDest, lpSrc);
> >>> +    TRACE("(%p, %s)\n", *lppDest, debugstr_a(lpSrc));
> >>> +
> >>> +    if (*lppDest) {
> >>> +        ERR("lppDest should be NULL!");
> >>> +        return FALSE;
> >>> +    }
> >> It's an internal call, so it's better to require a caller to pass valid
> >> parameters. That's why ERR is too much here, cause you completely
> >> control passed parameters in a first place.
> > The problem is, this function return FALSE if some thing going wrong,
> > but caller never check it. So if we pass fresh not NULL, not Alloc'd
> > pointer. We have some garbage in pointers target before the call. After
> > ReAlloc and Str_SetPtrAtoW failed, caller continues to use old pointers
> > target, also old garbage. The App get garbage instead of the string and
> > will crash in some conditions. This all make it hard to find the cause
> > of the crash.
> I'll try to explain again.
> 
> Str_SetPtrAtoW() is not a public API call, so it's not accessible directly from outside
> comctl32. My request to you was to provide a simple test application that uses some comctl32 controls
> presumably and indirectly makes use of this call (and fails for some reason you'll trying to find).
> 
> >> Please open a bug with a test C application so we can look at initial
> >> problem.
> > Das Not ReAllocing not Alloc'd memory is bug? or it is future?
> It depends.
> > Here is part of man realloc:
> >
> >> realloc() changes the size of the memory block pointed  to  by  ptr  to
> >>         size  bytes.   The contents will be unchanged to the minimum of the old
> >>         and new sizes; newly allocated memory will be uninitialized.  If ptr is
> >>         NULL,  then  the  call is equivalent to malloc(size), for all values of
> >>         size; if size is equal to zero, and ptr is not NULL, then the  call  is
> >>         equivalent  to  free(ptr).   Unless  ptr  is  NULL,  it  must have been
> >>         returned by an earlier call to malloc(), calloc() or realloc().  If the
> >>         area pointed to was moved, a free(ptr) is done.
> > This is irrelevant here.

I need to apologize. Wine a big mystery for me.
And it seems like the string corruption i talked about, i introduced by
my self.
And i see you send the patch to test the strings:
comctl32/tests: Cleanup MRU lists tests, add more

At least i got the target and found how to workaround my bug
http://bugs.winehq.org/show_bug.cgi?id=26923
:D
-- 
Regards,
        Alexey