C++ / JNI memory leakage, help needed

[Sambucus]

Hi group!

I am using C++ and java with JNI to get some text in a RICHEDIT to my
java program. I do so by accessing a C++ method every second. It all
works fine except that it leaks memory every call I make to the C++
method.

Can anyone please help me with this problem? I am not sure wether the
leakage is in the C++ or java code. But i guess it's on the C++ side
since I'm kind of newbee there.

Is there perhaps a way to release the memory allocated for a LPTSTR in
C++?
Please take a look at the code below, it is the method i call every
second from java. I belive it is the LPTSTR that is leaking, since it
leaks more when the string gets larger.

<---------------
LPTSTR output;

JNIEXPORT jstring JNICALL
Java_JNIHandler _getDealerOutpu t(JNIEnv *env, jobject obj){

size = SendMessage(
(HWND) textarea, // handle to destination window
WM_GETTEXTLENGT H, // message to send
(WPARAM) 0,
(LPARAM) 0 ) +1;

output = new TCHAR[size];

SendMessage(tex tarea,
WM_GETTEXT,
size,
(LPARAM)(void*) output);

return env->NewStringUTF(d ealerStr);

}
------------------>

I have tried to release the memory allocated when the NewStringUTF is
made with the JNI.h method env -> ReleaseStringUT FChars(str,
dealerStr) to no avail.
I hae also tried to use a try/finally block and in the finally set:
output= NULL; delete output; but there is no difference.

Cheers
Andreas

[Jorge Rivera]

John Harrison wrote:

"Sambucus" <an************ ***@aetdata.com > wrote in message
news:d3******** *************** ***@posting.goo gle.com...

Hi group!

I am using C++ and java with JNI to get some text in a RICHEDIT to my
java program. I do so by accessing a C++ method every second. It all
works fine except that it leaks memory every call I make to the C++
method.

Can anyone please help me with this problem? I am not sure wether the
leakage is in the C++ or java code. But i guess it's on the C++ side
since I'm kind of newbee there.

Is there perhaps a way to release the memory allocated for a LPTSTR in
C++?
Please take a look at the code below, it is the method i call every
second from java. I belive it is the LPTSTR that is leaking, since it
leaks more when the string gets larger.

<---------------
LPTSTR output;

JNIEXPORT jstring JNICALL
Java_JNIHandl er_getDealerOut put(JNIEnv *env, jobject obj){

size = SendMessage(
(HWND) textarea, // handle to destination window
WM_GETTEXTLEN GTH, // message to send
(WPARAM) 0,
(LPARAM) 0 ) +1;

output = new TCHAR[size];

SendMessage(t extarea,
WM_GETTEXT,
size,
(LPARAM)(void *)output);

return env->NewStringUTF(d ealerStr);

}
------------------>

I have tried to release the memory allocated when the NewStringUTF is
made with the JNI.h method env -> ReleaseStringUT FChars(str,
dealerStr) to no avail.
I hae also tried to use a try/finally block and in the finally set:
output= NULL; delete output; but there is no difference.

finally is not part of the C++ language

Try this

jstring res = env->NewStringUTF(d ealerStr);
delete[] output;

It's been a while since I last used JNI, but I think that strings that
you create using NewStringUTF must be deleted (I don't remember the
syntax for this).

Check Sun's web site for more details on NewStringUTF...

JLR

[Chris Uppal]

Yoyoma_2 wrote:

James Gregory wrote:
[...]
If you alwaise test on NULL then you are fine. What happends if you
need to write to the 0x0 memory area in an albeit wierd platform.

You are wrong. The value 0 when used as a pointer has special defined
semantics in both C and C++. Check the standards for the details.

I'd write more except that:

(a) this is cross-posted into areas where nobody is even slightly interested in
the oddities of the C/C++ standards.

(b) it's a few years since I last attempted public pedantry on these topics, so
I'm a little rusty...

-- chris

[Chris Uppal]

Yoyoma_2 wrote:

James Gregory wrote:
[...]
If you alwaise test on NULL then you are fine. What happends if you
need to write to the 0x0 memory area in an albeit wierd platform.

You are wrong. The value 0 when used as a pointer has special defined
semantics in both C and C++. Check the standards for the details.

I'd write more except that:

(a) this is cross-posted into areas where nobody is even slightly interested in
the oddities of the C/C++ standards.

(b) it's a few years since I last attempted public pedantry on these topics, so
I'm a little rusty...

-- chris

[Kevin Goodsell]

James Gregory wrote:

On Sat, 03 Apr 2004 17:07:10 +0000, Yoyoma_2 wrote:

This isn't java related but alwaise set your variables to NULL, since
some platforms could exist that NULL is not defined as 0x0.

I'm sure I've seen someone else on this group before say "Always set your
variables to 0 rather than to NULL, some platforms may exist where NULL
isn't defined as 0".

NULL must be a constant expression equal to 0. There is absolutely no
difference between using NULL and 0.

4.10 Pointer conversions [conv.ptr]

1 A null pointer constant is an integral constant expression
(_expr.const_) rvalue of integer type that evaluates to zero.

18.1 Types [lib.support.typ es]

[...]

4 The macro NULL is an implementation-defined C++ null pointer constant
in this International Standard (_conv.ptr_).18 0)

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

James Gregory wrote:

On Sat, 03 Apr 2004 17:07:10 +0000, Yoyoma_2 wrote:

This isn't java related but alwaise set your variables to NULL, since
some platforms could exist that NULL is not defined as 0x0.

I'm sure I've seen someone else on this group before say "Always set your
variables to 0 rather than to NULL, some platforms may exist where NULL
isn't defined as 0".

NULL must be a constant expression equal to 0. There is absolutely no
difference between using NULL and 0.

4.10 Pointer conversions [conv.ptr]

1 A null pointer constant is an integral constant expression
(_expr.const_) rvalue of integer type that evaluates to zero.

18.1 Types [lib.support.typ es]

[...]

4 The macro NULL is an implementation-defined C++ null pointer constant
in this International Standard (_conv.ptr_).18 0)

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Sambucus]

>

finally is not part of the C++ language

Try this

jstring res = env->NewStringUTF(d ealerStr);
delete[] output;
return res;

I guess you are more of a Java programmer than a C++ programmer.

Another method would be to use a vector, then you wouldn't have to worry
about memory allocation.

size = SendMessage(tex tarea, WM_GETTEXTLENGT H, 0, 0);
std::vector<TCH AR> output(size + 1);
SendMessage(tex tarea, WM_GETTEXT, size, (LPARAM)(void*) &output[0]);
return env->NewStringUTF(& output[0]);

I'm a bit hazy on the Windows and JNI details but the bottom line is that if
you allocate memory with new[] then you have to free it with delete[], and
if you use a vector then you don't have to deallocate at all.

john

You are certainly corect about me beeing a Java programer and not C++
;)
I tried the first approach and it worked fine, thank you very much
John!¨

However i had tried to use something like this:

return env->NewStringUTF(o utput);

}
__finally
{
output= NULL;
delete [] output;
size=NULL;

....and it did not work, i guess it has to do with the __finally not
beeing part of c++? but why don't I get compilation a error?

//Andreas

[Sambucus]

>

finally is not part of the C++ language

Try this

jstring res = env->NewStringUTF(d ealerStr);
delete[] output;
return res;

I guess you are more of a Java programmer than a C++ programmer.

Another method would be to use a vector, then you wouldn't have to worry
about memory allocation.

size = SendMessage(tex tarea, WM_GETTEXTLENGT H, 0, 0);
std::vector<TCH AR> output(size + 1);
SendMessage(tex tarea, WM_GETTEXT, size, (LPARAM)(void*) &output[0]);
return env->NewStringUTF(& output[0]);

I'm a bit hazy on the Windows and JNI details but the bottom line is that if
you allocate memory with new[] then you have to free it with delete[], and
if you use a vector then you don't have to deallocate at all.

john

You are certainly corect about me beeing a Java programer and not C++
;)
I tried the first approach and it worked fine, thank you very much
John!¨

However i had tried to use something like this:

return env->NewStringUTF(o utput);

}
__finally
{
output= NULL;
delete [] output;
size=NULL;

....and it did not work, i guess it has to do with the __finally not
beeing part of c++? but why don't I get compilation a error?

//Andreas

[Sambucus]

> It's been a while since I last used JNI, but I think that strings that

you create using NewStringUTF must be deleted (I don't remember the
syntax for this).

Check Sun's web site for more details on NewStringUTF...

JLR

Well i stumbled on info regarding this appearantly by Sun undocumented
memory leakage in JNI when trying to solve my problem.

However this is only when you are sending a java String to the C dll.
In the C code you have to get a C string from the Java UTF chars...
then you must use "env -> ReleaseStringUT FChars(str,outp ut)" to
release it

[Sambucus]

> It's been a while since I last used JNI, but I think that strings that

you create using NewStringUTF must be deleted (I don't remember the
syntax for this).

Check Sun's web site for more details on NewStringUTF...

JLR

Well i stumbled on info regarding this appearantly by Sun undocumented
memory leakage in JNI when trying to solve my problem.

However this is only when you are sending a java String to the C dll.
In the C code you have to get a C string from the Java UTF chars...
then you must use "env -> ReleaseStringUT FChars(str,outp ut)" to
release it

[lev]

function c_str() returns const <CHAR_TYPE> *
"John Harrison" <jo************ *@hotmail.com> wrote in message
news:c4******** *****@ID-196037.news.uni-berlin.de...

What John said, but consider using a std::basic_stri ng<TCHAR> instead of
std::vector<TCH AR>. The basic string in C++ has more Java-like syntax,
e.g. the operator [ ] is range-checked, and concatenation can be done
with operator +.
But the problem with std::basic_stri ng is that you cannot get a writable
pointer from it. Therefore it's not suitable for passing to

SendMessage(win , WM_GETTEXT ...).

john