[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xorg
Subject: RE: XI2's copyRawEvent() question
From: "Roger Cruz" <roger.cruz () virtualcomputer ! com>
Date: 2011-04-25 20:52:00
Message-ID: EACA7CA90354A849B1315959042A052C010945CB () BE24 ! exg4 ! exghost ! com
[Download RAW message or body]
--===============1409901141==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01CC038A.9FC9A77F"
This is a multi-part message in MIME format.
BTW, changing the code to use "len" rather than the sizeof() fixed my crash.
diff ../../libXi-1.3-orig/src/XExtInt.c src/XExtInt.c
1196c1196
< ptr = cookie_out->data = malloc(sizeof(XIRawEvent));
---
> ptr = cookie_out->data = malloc(len);
-----Original Message-----
From: xorg-bounces+roger.cruz=virtualcomputer.com@lists.freedesktop.org on behalf of \
Roger Cruz
Sent: Mon 4/25/2011 3:35 PM
To: xorg@lists.freedesktop.org
Subject: XI2's copyRawEvent() question
In trying to understand a heap corruption when I added XI2 RawMotion event handling \
to our Xinput-based application, I came across the following routine copyRawEvent() \
in libxi-1.3/src/XExtInt.c. My question is what is the purpose of computing "len" if \
it is not used? Should it have been used as an argument to malloc().
copyRawEvent(XGenericEventCookie *cookie_in,
XGenericEventCookie *cookie_out)
{
XIRawEvent *in, *out;
void *ptr;
int len;
int bits;
in = cookie_in->data;
bits = count_bits(in->valuators.mask, in->valuators.mask_len);
len = sizeof(XIRawEvent) + in->valuators.mask_len;
len += bits * sizeof(double) * 2;
ptr = cookie_out->data = malloc(sizeof(XIRawEvent));
if (!ptr)
return False;
out = next_block(&ptr, sizeof(XIRawEvent));
*out = *in;
out->valuators.mask = next_block(&ptr, out->valuators.mask_len);
memcpy(out->valuators.mask, in->valuators.mask, out->valuators.mask_len);
out->valuators.values = next_block(&ptr, bits * sizeof(double));
memcpy(out->valuators.values, in->valuators.values, bits * sizeof(double));
out->raw_values = next_block(&ptr, bits * sizeof(double));
memcpy(out->raw_values, in->raw_values, bits * sizeof(double));
return True;
}
When I use valgrind, I get the following output as the culprit for the crash
==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)
Thanks in advance,
Roger R. Cruz
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.894 / Virus Database: 271.1.1/3583 - Release Date: 04/25/11 02:34:00
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: XI2's copyRawEvent() question</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>BTW, changing the code to use "len" rather than the \
sizeof() fixed my crash.<BR> <BR>
diff ../../libXi-1.3-orig/src/XExtInt.c src/XExtInt.c<BR>
1196c1196<BR>
< ptr = cookie_out->data = \
malloc(sizeof(XIRawEvent));<BR>
---<BR>
> ptr = cookie_out->data = malloc(len);<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: xorg-bounces+roger.cruz=virtualcomputer.com@lists.freedesktop.org on behalf of \
Roger Cruz<BR>
Sent: Mon 4/25/2011 3:35 PM<BR>
To: xorg@lists.freedesktop.org<BR>
Subject: XI2's copyRawEvent() question<BR>
<BR>
<BR>
In trying to understand a heap corruption when I added XI2 RawMotion event handling \
to our Xinput-based application, I came across the following routine copyRawEvent() \
in libxi-1.3/src/XExtInt.c. My question is what is the purpose of computing \
"len" if it is not used? Should it have been used as an argument to \
malloc().<BR> <BR>
copyRawEvent(XGenericEventCookie *cookie_in,<BR>
\
XGenericEventCookie *cookie_out)<BR> {<BR>
XIRawEvent *in, *out;<BR>
void *ptr;<BR>
int len;<BR>
int bits;<BR>
<BR>
in = cookie_in->data;<BR>
<BR>
bits = count_bits(in->valuators.mask, \
in->valuators.mask_len);<BR> len = sizeof(XIRawEvent) + \
in->valuators.mask_len;<BR> len += bits * sizeof(double) * \
2;<BR> <BR>
ptr = cookie_out->data = malloc(sizeof(XIRawEvent));<BR>
if (!ptr)<BR>
return False;<BR>
<BR>
out = next_block(&ptr, sizeof(XIRawEvent));<BR>
*out = *in;<BR>
out->valuators.mask = next_block(&ptr, \
out->valuators.mask_len);<BR> memcpy(out->valuators.mask, \
in->valuators.mask, out->valuators.mask_len);<BR> <BR>
out->valuators.values = next_block(&ptr, bits * \
sizeof(double));<BR> memcpy(out->valuators.values, \
in->valuators.values, bits * sizeof(double));<BR> <BR>
out->raw_values = next_block(&ptr, bits * \
sizeof(double));<BR> memcpy(out->raw_values, in->raw_values, \
bits * sizeof(double));<BR> <BR>
return True;<BR>
}<BR>
<BR>
When I use valgrind, I get the following output as the culprit for the crash<BR>
<BR>
==4166== Invalid write of size 1<BR>
==4166== at 0x4C29F04: memcpy (mc_replace_strmem.c:497)<BR>
==4166== by 0x8F39180: ??? (in /usr/lib/libXi.so.6.1.0)<BR>
==4166== by 0x7433D48: _XCopyEventCookie (in \
/usr/lib/libX11.so.6.3.0)<BR> ==4166== by 0x7425166: XPeekEvent (in \
/usr/lib/libX11.so.6.3.0)<BR> ==4166== by 0x49C3E3: process_key \
(x11_be.c:1065)<BR> ==4166== by 0x49EA5C: event_key_release \
(x11_be.c:2201)<BR> ==4166== by 0x49DD6E: x11_be_process_events \
(x11_be.c:1892)<BR> ==4166== by 0x4A38F4: x11_be_main_loop \
(x11_be.c:4353)<BR> ==4166== by 0x4A39E1: x11_be_thread_main \
(x11_be.c:4385)<BR> ==4166== by 0x87549C9: start_thread \
(pthread_create.c:300)<BR> ==4166== by 0x8A516FC: clone \
(clone.S:112)<BR> ==4166== Address 0x168afe80 is 0 bytes after a block of size \
96 alloc'd<BR> ==4166== at 0x4C284A8: malloc \
(vg_replace_malloc.c:236)<BR> ==4166== by 0x8F390BD: ??? (in \
/usr/lib/libXi.so.6.1.0)<BR> ==4166== by 0x7433D48: \
_XCopyEventCookie (in /usr/lib/libX11.so.6.3.0)<BR> ==4166== by \
0x7425166: XPeekEvent (in /usr/lib/libX11.so.6.3.0)<BR> ==4166== by \
0x49C3E3: process_key (x11_be.c:1065)<BR> ==4166== by 0x49EA5C: \
event_key_release (x11_be.c:2201)<BR> ==4166== by 0x49DD6E: \
x11_be_process_events (x11_be.c:1892)<BR> ==4166== by 0x4A38F4: \
x11_be_main_loop (x11_be.c:4353)<BR> ==4166== by 0x4A39E1: \
x11_be_thread_main (x11_be.c:4385)<BR> ==4166== by 0x87549C9: \
start_thread (pthread_create.c:300)<BR> <BR>
Thanks in advance,<BR>
<BR>
Roger R. Cruz<BR>
<BR>
No virus found in this incoming message.<BR>
Checked by AVG - www.avg.com<BR>
Version: 9.0.894 / Virus Database: 271.1.1/3583 - Release Date: 04/25/11 02:34:00<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: freedesktop-xorg@progressive-comp.com
--===============1409901141==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic