You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Leif Nilsson TACMa <le...@tac.se> on 2002/08/16 11:39:30 UTC
RE: COMProvider patch
Hi,
Further testing has shown that the added ::SysFreeString was no success.
The attached file has removed the ::SysFreeString call but kept the
::VariantClear calls.
Can anyone explain why the allocated bstr-string should not be deallocated ?
The code is as follows:
extern "C" JNIEXPORT jbyteArray JNICALL
Java_org_apache_soap_providers_com_RPCProvider_nativeConvertToBString(JNIEnv
*env, jclass jc, jstring s)
{
env->ExceptionClear(); //Let a calling thread to invoke a call record the
error.
jboolean isCopy;
const wchar_t * cs= env->GetStringChars(s, &isCopy);
BSTR bstrS=SysAllocString(cs);
// Allocating new string as copy of cs
if(isCopy == JNI_TRUE) env->ReleaseStringChars(s, cs);
jbyteArray jByteArray= env->NewByteArray(sizeof bstrS);
jbyte *jr= env->GetByteArrayElements(jByteArray, &isCopy);
void *x =bstrS;
// pointer for the string
memcpy(jr, &x, sizeof x);
// copy string
if(isCopy == JNI_TRUE) env->ReleaseByteArrayElements(jByteArray,jr,0);
::SysFreeString(bstrS); // WRONG !!!!!!!!!
// Deallocate string - WRONG !!!!!!!!!
return jByteArray;
}
<<RPCProvider.cpp>>
> -----Original Message-----
> From: Leif Nilsson TACMa
> Sent: Wednesday, July 03, 2002 15:43
> To: soap-dev@xml.apache.org
> Subject: COMProvider patch and ssl question
>
> Hi,
>
> COMPROVIDER
> ==============
> Two memory leaks have now been fixed in RPCProvider.cpp.
> If you compare the original version with the new one you'll find two calls
> to
> ::VariantClear(&result);
> And one call to
> ::SysFreeString(bstrS);
>
> I'm not 100% sure that all leaks are handled but it is much better.
>
> Review it and perhaps add it ?
>
> << File: RPCProvider.cpp >>
> SSL-question
> ==========
> I use Java 1.4.0 and Apache soap 2.2
> Furthermore I use https with client and server certificates.
> If I call repeatadly it seems that the client just loose the connection
> now and again. As this happens the call takes "0" seconds as supposed
> to the normal 2-5 seconds. The result is a SOAP-exception that says that
> no HTTP-status has been returned.
>
> I have no clue as to where the problem lies. For each call I create a new
> SOAPHTTPConnection.
> Can anyone tell me if I'm supposed to do something special or maybe
> explain how I can
> find out why the HTTP-status is not there (i.e. why the socket (?) just
> went tired)...
>
> If I use plain HTTP this does not happen.
>
> /Leif
>
> Leif Nilsson
> Software Engineer
>
> TAC AB
> Jägershillgatan 18
> SE-213 75 Malmö, Sweden
> Direct +46 40 38 69 56
> Fax +46 40 21 82 87
> Mobile +46 xx xxx xx xx
> www.tac-global.com
>
> This email is intended only for the use of the individual or entity to
> whom it is addressed. It may contain information that is privileged,
> confidential or otherwise protected from disclosure under applicable law.
> If you have received this transmission in error, please delete it
> immediately and notify me by mailing me.
>
>
Re: COMProvider patch
Posted by Scott Nichol <sn...@scottnichol.com>.
It appears to me that the code does not make a copy of the BSTR, just of its
address. If you free it, the copy of its address will point to a free
block. That's just based on a look at this without knowing anything about
the member functions of JNIEnv.
The lines of code are
void *x =bstrS;
memcpy(jr, &x, sizeof x);
Frankly, I don't see how these differ from
jr = (jbyte *) bstrS;
Scott Nichol
----- Original Message -----
From: "Leif Nilsson TACMa" <le...@tac.se>
To: <so...@xml.apache.org>
Sent: Friday, August 16, 2002 5:39 AM
Subject: RE: COMProvider patch
Hi,
Further testing has shown that the added ::SysFreeString was no success.
The attached file has removed the ::SysFreeString call but kept the
::VariantClear calls.
Can anyone explain why the allocated bstr-string should not be deallocated ?
The code is as follows:
extern "C" JNIEXPORT jbyteArray JNICALL
Java_org_apache_soap_providers_com_RPCProvider_nativeConvertToBString(JNIEnv
*env, jclass jc, jstring s)
{
env->ExceptionClear(); //Let a calling thread to invoke a call record the
error.
jboolean isCopy;
const wchar_t * cs= env->GetStringChars(s, &isCopy);
BSTR bstrS=SysAllocString(cs);
// Allocating new string as copy of cs
if(isCopy == JNI_TRUE) env->ReleaseStringChars(s, cs);
jbyteArray jByteArray= env->NewByteArray(sizeof bstrS);
jbyte *jr= env->GetByteArrayElements(jByteArray, &isCopy);
void *x =bstrS;
// pointer for the string
memcpy(jr, &x, sizeof x);
// copy string
if(isCopy == JNI_TRUE) env->ReleaseByteArrayElements(jByteArray,jr,0);
::SysFreeString(bstrS); // WRONG !!!!!!!!!
// Deallocate string - WRONG !!!!!!!!!
return jByteArray;
}
<<RPCProvider.cpp>>
> -----Original Message-----
> From: Leif Nilsson TACMa
> Sent: Wednesday, July 03, 2002 15:43
> To: soap-dev@xml.apache.org
> Subject: COMProvider patch and ssl question
>
> Hi,
>
> COMPROVIDER
> ==============
> Two memory leaks have now been fixed in RPCProvider.cpp.
> If you compare the original version with the new one you'll find two calls
> to
> ::VariantClear(&result);
> And one call to
> ::SysFreeString(bstrS);
>
> I'm not 100% sure that all leaks are handled but it is much better.
>
> Review it and perhaps add it ?
>
> << File: RPCProvider.cpp >>
> SSL-question
> ==========
> I use Java 1.4.0 and Apache soap 2.2
> Furthermore I use https with client and server certificates.
> If I call repeatadly it seems that the client just loose the connection
> now and again. As this happens the call takes "0" seconds as supposed
> to the normal 2-5 seconds. The result is a SOAP-exception that says that
> no HTTP-status has been returned.
>
> I have no clue as to where the problem lies. For each call I create a new
> SOAPHTTPConnection.
> Can anyone tell me if I'm supposed to do something special or maybe
> explain how I can
> find out why the HTTP-status is not there (i.e. why the socket (?) just
> went tired)...
>
> If I use plain HTTP this does not happen.
>
> /Leif
>
> Leif Nilsson
> Software Engineer
>
> TAC AB
> Jägershillgatan 18
> SE-213 75 Malmö, Sweden
> Direct +46 40 38 69 56
> Fax +46 40 21 82 87
> Mobile +46 xx xxx xx xx
> www.tac-global.com
>
> This email is intended only for the use of the individual or entity to
> whom it is addressed. It may contain information that is privileged,
> confidential or otherwise protected from disclosure under applicable law.
> If you have received this transmission in error, please delete it
> immediately and notify me by mailing me.
>
>
----------------------------------------------------------------------------
----
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: COMProvider patch
Posted by Scott Nichol <sn...@scottnichol.com>.
It appears to me that the code does not make a copy of the BSTR, just of its
address. If you free it, the copy of its address will point to a free
block. That's just based on a look at this without knowing anything about
the member functions of JNIEnv.
The lines of code are
void *x =bstrS;
memcpy(jr, &x, sizeof x);
Frankly, I don't see how these differ from
jr = (jbyte *) bstrS;
Scott Nichol
----- Original Message -----
From: "Leif Nilsson TACMa" <le...@tac.se>
To: <so...@xml.apache.org>
Sent: Friday, August 16, 2002 5:39 AM
Subject: RE: COMProvider patch
Hi,
Further testing has shown that the added ::SysFreeString was no success.
The attached file has removed the ::SysFreeString call but kept the
::VariantClear calls.
Can anyone explain why the allocated bstr-string should not be deallocated ?
The code is as follows:
extern "C" JNIEXPORT jbyteArray JNICALL
Java_org_apache_soap_providers_com_RPCProvider_nativeConvertToBString(JNIEnv
*env, jclass jc, jstring s)
{
env->ExceptionClear(); //Let a calling thread to invoke a call record the
error.
jboolean isCopy;
const wchar_t * cs= env->GetStringChars(s, &isCopy);
BSTR bstrS=SysAllocString(cs);
// Allocating new string as copy of cs
if(isCopy == JNI_TRUE) env->ReleaseStringChars(s, cs);
jbyteArray jByteArray= env->NewByteArray(sizeof bstrS);
jbyte *jr= env->GetByteArrayElements(jByteArray, &isCopy);
void *x =bstrS;
// pointer for the string
memcpy(jr, &x, sizeof x);
// copy string
if(isCopy == JNI_TRUE) env->ReleaseByteArrayElements(jByteArray,jr,0);
::SysFreeString(bstrS); // WRONG !!!!!!!!!
// Deallocate string - WRONG !!!!!!!!!
return jByteArray;
}
<<RPCProvider.cpp>>
> -----Original Message-----
> From: Leif Nilsson TACMa
> Sent: Wednesday, July 03, 2002 15:43
> To: soap-dev@xml.apache.org
> Subject: COMProvider patch and ssl question
>
> Hi,
>
> COMPROVIDER
> ==============
> Two memory leaks have now been fixed in RPCProvider.cpp.
> If you compare the original version with the new one you'll find two calls
> to
> ::VariantClear(&result);
> And one call to
> ::SysFreeString(bstrS);
>
> I'm not 100% sure that all leaks are handled but it is much better.
>
> Review it and perhaps add it ?
>
> << File: RPCProvider.cpp >>
> SSL-question
> ==========
> I use Java 1.4.0 and Apache soap 2.2
> Furthermore I use https with client and server certificates.
> If I call repeatadly it seems that the client just loose the connection
> now and again. As this happens the call takes "0" seconds as supposed
> to the normal 2-5 seconds. The result is a SOAP-exception that says that
> no HTTP-status has been returned.
>
> I have no clue as to where the problem lies. For each call I create a new
> SOAPHTTPConnection.
> Can anyone tell me if I'm supposed to do something special or maybe
> explain how I can
> find out why the HTTP-status is not there (i.e. why the socket (?) just
> went tired)...
>
> If I use plain HTTP this does not happen.
>
> /Leif
>
> Leif Nilsson
> Software Engineer
>
> TAC AB
> Jägershillgatan 18
> SE-213 75 Malmö, Sweden
> Direct +46 40 38 69 56
> Fax +46 40 21 82 87
> Mobile +46 xx xxx xx xx
> www.tac-global.com
>
> This email is intended only for the use of the individual or entity to
> whom it is addressed. It may contain information that is privileged,
> confidential or otherwise protected from disclosure under applicable law.
> If you have received this transmission in error, please delete it
> immediately and notify me by mailing me.
>
>
----------------------------------------------------------------------------
----
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>