X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C80B95.9D82F76B@onstor-exch02.onstor.net>; Wed, 10 Oct 2007 15:31:00 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C80B95.9D82F76B"
Content-class: urn:content-classes:message
Subject: dmalloc question
Date: Wed, 10 Oct 2007 15:31:00 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E030E38E1@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: dmalloc question
Thread-Index: AcgLlZ0K4kn0ISoJRzer0mOb2hXVGw==
From: "Mike Lee" <mike.lee@onstor.com>
To: "dl-Cougar" <dl-Cougar@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C80B95.9D82F76B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

To the software members of the team:

Concerning the dmalloc error from eventd that Max collected...

The dmalloc log indicates the following:
1192040788: 3426: process pid =3D 1816
1192040788: 3426:   error details: pointer-check
1192040788: 3426:   pointer '0x2aaeec78' from 'unknown' prev access =
'rmc_api.c:2061'
1192040788: 3426: ERROR: memcpy: use of pointer would exceed allocation =
(err 28)

While the stack frames of interest from the corresponding eventd core =
are:
#8  0x2b581134 in _dmalloc_memcpy (file=3D0x40dc80 "event.c", =
line=3D591, to=3D0x2aae1078, from=3D0x2aaeec78, len=3D1248) at =
arg_check.c:251
#9  0x00403be8 in rmc_async_send (sess=3D0x484aa0, buf=3D0x2aaeec78, =
bufsz=3D1248, tag=3D0, rpc_id=3D0, mode=3D8) at event.c:591
#10 0x00404638 in event_forwardToLocalApps (eventMsg=3D0x2aaeec78, =
eventId=3D36) at event.c:719

Focusing on Frame 9 where the memcpy() call resides:
event.c, rmc_async_send()
    578 rmc_async_send(evt_rmc_session_t *sess, void *buf, ssize_t =
bufsz,
    579                    uint32_t tag, uint32_t rpc_id, uint32_t mode)
    580 {
:
    585     msg =3D (rmc_msg_t *)rmc_alloc_msg(bufsz);
    586     if (msg =3D=3D NULL) {
    587         ASSERT(0);
    588         return RMC_NOMEM;
    589     }
    590
    591     memcpy(msg->sg_list[0].buf, buf, bufsz);

It would appear that perhaps rmc_alloc_msg() is not allocating enough.
However, my review of rmc_alloc_msg(), with help from Rendell, did not =
identify any problem.
   2054 API rmc_msg_t *
   2055 rmc_alloc_msg(int32 sz)
   2056 {
   2057     rmc_msg_t *msg;
   2058=20
   2059     if (!(msg =3D (rmc_msg_t *)calloc(sizeof(rmc_msg_t) + sz, =
1))) {
   2060         //return NULL;
   2061         // May be leaking memory.  Abort and let pm restart the =
daemons.
   2062         abort();
   2063     }
   2064=20
   2065     if (sz) {
   2066         msg->sg_cnt =3D 1;
   2067         msg->sg_list[0].buf =3D ((char *)msg + =
sizeof(rmc_msg_t));  <=3D=3D=3D=3D=3D=3D=3D I think this setting is =
okay, though unconventional
   2068         msg->sg_list[0].len =3D sz;
   2069         msg->ihdr.msg_len =3D sz;
   2070=20
   2071     } else {
   2072         msg->sg_cnt =3D 0;
   2073         msg->ihdr.msg_len =3D 0;
   2074     }
   2075=20
   2076     /* JTOF - we set the type here (negative for RMC) so apps =
know
   2077      * if they did the alloc or the RMC layer did. It's not =
checked
   2078      * by the free routine because we alloc mallocs - if/when a=20
   2079      * pre-allocated list is added, this flag will be used to=20
   2080      * mark these messages
   2081      */
   2082     msg->memtyp =3D -1;
   2083     return msg;
   2084 }

Though the single call to calloc() is a little unusual, I don't see a =
problem with this efficient logic.
So, my question is: could dmalloc report false-positives?
Also, should I break this calloc call into two calls (one for msg and =
the other for buf), for sake of clarity?

Thanks.

-Mike

------_=_NextPart_001_01C80B95.9D82F76B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>dmalloc question</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">To the software members of the =
team:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Concerning the dmalloc error from =
eventd that Max collected...</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The dmalloc log indicates the =
following:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">1192040788: 3426: process pid =3D =
1816</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">1192040788: 3426:&nbsp;&nbsp; error =
details: pointer-check</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">1192040788: 3426:&nbsp;&nbsp; pointer =
'0x2aaeec78' from 'unknown' prev access 'rmc_api.c:2061'</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">1192040788: 3426: ERROR: memcpy: use =
of pointer would exceed allocation (err 28)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">While the stack frames of interest from =
the corresponding eventd core are:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">#8&nbsp; 0x2b581134 in _dmalloc_memcpy =
(file=3D0x40dc80 &quot;event.c&quot;, line=3D591, to=3D0x2aae1078, =
from=3D0x2aaeec78, len=3D1248) at arg_check.c:251</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">#9&nbsp; 0x00403be8 in rmc_async_send =
(sess=3D0x484aa0, buf=3D0x2aaeec78, bufsz=3D1248, tag=3D0, rpc_id=3D0, =
mode=3D8) at event.c:591</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">#10 0x00404638 in =
event_forwardToLocalApps (eventMsg=3D0x2aaeec78, eventId=3D36) at =
event.c:719</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Focusing on Frame 9 where the memcpy() =
call resides:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">event.c, rmc_async_send()</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; 578 =
rmc_async_send(evt_rmc_session_t *sess, void *buf, ssize_t bufsz,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
579&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; uint32_t tag, uint32_t =
rpc_id, uint32_t mode)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; 580 {</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
585&nbsp;&nbsp;&nbsp;&nbsp; msg =3D (rmc_msg_t =
*)rmc_alloc_msg(bufsz);</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
586&nbsp;&nbsp;&nbsp;&nbsp; if (msg =3D=3D NULL) {</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
587&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASSERT(0);</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
588&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return =
RMC_NOMEM;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
589&nbsp;&nbsp;&nbsp;&nbsp; }</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; 590</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
591&nbsp;&nbsp;&nbsp;&nbsp; memcpy(msg-&gt;sg_list[0].buf, buf, =
bufsz);</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It would appear that perhaps =
rmc_alloc_msg() is not allocating enough.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">However, my review of rmc_alloc_msg(), =
with help from Rendell, did not identify any problem.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; 2054 API rmc_msg_t =
*</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; 2055 rmc_alloc_msg(int32 =
sz)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; 2056 {</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2057&nbsp;&nbsp;&nbsp;&nbsp; rmc_msg_t *msg;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; 2058 </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2059&nbsp;&nbsp;&nbsp;&nbsp; if (!(msg =3D (rmc_msg_t =
*)calloc(sizeof(rmc_msg_t) + sz, 1))) {</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2060&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //return =
NULL;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2061&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // May be leaking =
memory.&nbsp; Abort and let pm restart the daemons.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2062&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; abort();</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2063&nbsp;&nbsp;&nbsp;&nbsp; }</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; 2064 </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2065&nbsp;&nbsp;&nbsp;&nbsp; if (sz) {</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2066&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; msg-&gt;sg_cnt =3D =
1;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2067&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
msg-&gt;sg_list[0].buf =3D ((char *)msg + sizeof(rmc_msg_t));&nbsp; =
&lt;=3D=3D=3D=3D=3D=3D=3D I think this setting is okay, though =
unconventional</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2068&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
msg-&gt;sg_list[0].len =3D sz;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2069&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
msg-&gt;ihdr.msg_len =3D sz;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; 2070 </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2071&nbsp;&nbsp;&nbsp;&nbsp; } else {</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2072&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; msg-&gt;sg_cnt =3D =
0;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2073&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
msg-&gt;ihdr.msg_len =3D 0;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2074&nbsp;&nbsp;&nbsp;&nbsp; }</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; 2075 </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2076&nbsp;&nbsp;&nbsp;&nbsp; /* JTOF - we set the type here (negative =
for RMC) so apps know</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2077&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * if they did the alloc or the RMC =
layer did. It's not checked</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2078&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * by the free routine because we =
alloc mallocs - if/when a </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2079&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * pre-allocated list is added, this =
flag will be used to </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2080&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * mark these messages</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2081&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; */</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2082&nbsp;&nbsp;&nbsp;&nbsp; msg-&gt;memtyp =3D -1;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
2083&nbsp;&nbsp;&nbsp;&nbsp; return msg;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; 2084 }</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Though the single call to calloc() is a =
little unusual, I don't see a problem with this efficient logic.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">So, my question is: could dmalloc =
report false-positives?</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Also, should I break this calloc call =
into two calls (one for msg and the other for buf), for sake of =
clarity?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-Mike</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C80B95.9D82F76B--
