[PATCH libXi] Allocate enough memory for raw events + extra data.

Jeremy Huddleston jeremyhu at apple.com
Mon May 2 23:00:35 PDT 2011


On May 2, 2011, at 10:00 PM, Peter Hutterer wrote:

> On Mon, May 02, 2011 at 09:05:21PM -0700, Jeremy Huddleston wrote:
>> Woot.  That takes care of:
>> 
>> http://people.freedesktop.org/~jeremyhu/analyzer/yuffie/20110429-1617/libXi/report-kzyPla.html#EndPath
>> 
>> It looks like there are others you might want to do at the same time:
>> http://people.freedesktop.org/~jeremyhu/analyzer/yuffie/20110429-1617/libXi/
> 
> re "Idempotent operation"
> I'm staring hard at those but don't really see the issue.
> SetReqLen(req, foo, foo); is valid and for any foo that is non-zero
> shouldn't have the effect of "Assigned value is always the same as the
> existing value". SetReqLen essentially does req->length += foo.

Yeah... "within expansion of macro..." results are a bit bad with clang.  I just opened a bug about that.  Hopefully future analytics will be better.  For now, at worse it's a dead assignment, and we can come back to it when clang gets better at printing those results.

> 
> http://people.freedesktop.org/~jeremyhu/analyzer/yuffie/20110429-1617/libXi/report-yDDyYj.html#EndPath
> "undefined allocation of 0 bytes" would be a server bug afaict

I dunno... is there anywhere that we guarantee that Xmalloc(0) returns NULL?  If so, then the macro should probably be ((size) > 0 ? malloc(size) : NULL) ... hopefully there is nothing actually using side-effects inside of Xmalloc(...) ...

> http://people.freedesktop.org/~jeremyhu/analyzer/yuffie/20110429-1617/libXi/report-n6GgtE.html#EndPath
> don't want to change this one, it's there for symmetry.

Would you mind doing this to shut up the warning?  I know it's ugly, but there unfortunately isn't a better way to whitelist in the analyzer yet:

#ifndef __clang_analyzer__
...
#endif


> 
> Cheers,
>  Peter
> 
>> On May 2, 2011, at 8:50 PM, Peter Hutterer wrote:
>> 
>>> Necessary space was calculated, but not actually used to allocate memory. As
>>> a result, valuator data would overwrite the allocated memory.
>>> 
>>> ==4166== Invalid write of size 1
>>> ==4166==    at 0x4C29F04: memcpy (mc_replace_strmem.c:497)
>>> ==4166==    by 0x8F39180: ??? (in /usr/lib/libXi.so.6.1.0)
>>> ==4166==    by 0x7433D48: _XCopyEventCookie (in /usr/lib/libX11.so.6.3.0)
>>> ==4166==    by 0x7425166: XPeekEvent (in /usr/lib/libX11.so.6.3.0)
>>> ==4166==    by 0x49C3E3: process_key (x11_be.c:1065)
>>> ==4166==    by 0x49EA5C: event_key_release (x11_be.c:2201)
>>> ==4166==    by 0x49DD6E: x11_be_process_events (x11_be.c:1892)
>>> ==4166==    by 0x4A38F4: x11_be_main_loop (x11_be.c:4353)
>>> ==4166==    by 0x4A39E1: x11_be_thread_main (x11_be.c:4385)
>>> ==4166==    by 0x87549C9: start_thread (pthread_create.c:300)
>>> ==4166==    by 0x8A516FC: clone (clone.S:112)
>>> ==4166==  Address 0x168afe80 is 0 bytes after a block of size 96 alloc'd
>>> ==4166==    at 0x4C284A8: malloc (vg_replace_malloc.c:236)
>>> ==4166==    by 0x8F390BD: ??? (in /usr/lib/libXi.so.6.1.0)
>>> ==4166==    by 0x7433D48: _XCopyEventCookie (in /usr/lib/libX11.so.6.3.0)
>>> ==4166==    by 0x7425166: XPeekEvent (in /usr/lib/libX11.so.6.3.0)
>>> ==4166==    by 0x49C3E3: process_key (x11_be.c:1065)
>>> ==4166==    by 0x49EA5C: event_key_release (x11_be.c:2201)
>>> ==4166==    by 0x49DD6E: x11_be_process_events (x11_be.c:1892)
>>> ==4166==    by 0x4A38F4: x11_be_main_loop (x11_be.c:4353)
>>> ==4166==    by 0x4A39E1: x11_be_thread_main (x11_be.c:4385)
>>> ==4166==    by 0x87549C9: start_thread (pthread_create.c:300)
>>> 
>>> Reported-by: Roger Cruz <roger.cruz at virtualcomputer.com>
>>> Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
>>> ---
>>> Sorry, was away for a number of days and only got to this now. You're right,
>>> it's a bug, copy/paste I guess.
>>> 
>>> src/XExtInt.c |    2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>> 
>>> diff --git a/src/XExtInt.c b/src/XExtInt.c
>>> index d1451cc..134ccc6 100644
>>> --- a/src/XExtInt.c
>>> +++ b/src/XExtInt.c
>>> @@ -1259,7 +1259,7 @@ copyRawEvent(XGenericEventCookie *cookie_in,
>>>    len = sizeof(XIRawEvent) + in->valuators.mask_len;
>>>    len += bits * sizeof(double) * 2;
>>> 
>>> -    ptr = cookie_out->data = malloc(sizeof(XIRawEvent));
>>> +    ptr = cookie_out->data = malloc(len);
>>>    if (!ptr)
>>>        return False;
>>> 
>>> -- 
>>> 1.7.4.4
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
> 



More information about the xorg-devel mailing list