Why cant I delete C++ pointer in JNI DLL

Hi,

I'm new to JNI and pretty rusty on C++, normally I stick to 100% Java, however I had a need for some native magic. My code works well and does the job I needed however my (old) knowledge of C++ tells me that I need to clean my objects up when I'm done. However I am unable to delete a pointer and I'm pretty sure its got something to do with JNI and lots to do with my lack of indepth knowledge. Here's what my code does.

I have a Java app (J) that statically loads my DLL

"J" calls a native c++ function within the DLL called (S).

"S" creates a C++ object using the "new" operator, called (T).

"T" is a Thread which I then start ( it runs for 1minute)

"S" does not wait for "T" to finish, instead it returns immediately, passing the pointer to "T" back to "J"

"J" then starts a normal Java Thread and every 10secs calls a native function from the DLL, called (C), and passes the pointer to "T".

"C" then checks "T" to find out if it has finished, if not then it returns % complete as an "int". If "T" has finished it throws an Exception, and then attempts to delete "T" calling the following code :-

delete T;

T = 0;

printf("\ndone\n");

However it crashed on "delete T", if I comment both these lines out everything completes ok.

My first thought was that "T" is already deleted, however I've checked and this is not the case, it still points to a valid "T" object. I know this because if I let my Java Thread continue to query for status long after "T" has stopped it still gets the last status message.

So my problem is, how do I delete "T"?. The system crashes if I try......interestingly enough though if I comment out the "delete T" line and leave the "T=0" line then I get an "Access Violation" error instead.

Does this mean that C++ does not own the object anymore (becase I passed it to Java). Does Java now own it and will it garbage collect it for me?

Thanks for any help

Chris.

[2032 byte] By [knightweba] at [2007-11-27 0:54:37]
# 1

Long but actually bit useless description :)

What is T really? Tell class name and is it standard class or your own? How do you create new object. Show exact line of code. Show how do you store and pass pointer to Java and back, show how do you use it, show how it crashes. What is "crashed" actually? Exception? Process failed? System reboot?

Michael.Nazarov@sun.coma at 2007-7-11 23:27:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 2

Sorry, it was very late when I posted, perhaps this will help :-

Java

public class IEConnectionJNI

{

public int iePtr;

static { Runtime.getRuntime().load( "C:\\IEConnectionJNI.dll" ); }

public native int startFileDownload( String sURL, String sSaveLocation, int iTimeout ) throws Exception;

public native String getDownloadStatus( int iDownloaderPointer ) throws Exception;

private class ProgressCheck extends Thread

{

IEConnectionJNI g_ieCon = null;

private ProgressCheck(){}

public ProgressCheck( IEConnectionJNI ieCon ){ g_ieCon = ieCon; }

public void run()

{

try

{

while(true)

{

sleep(2000);

String sStatus = g_ieCon.getDownloadStatus( g_ieCon.iePtr );

System.out.println("\n\ngot status=[" + sStatus + "]\n");

}

}catch(Exception e)

{

e.printStackTrace();

}

}

}

public static void main(String[] args )

{

IEConnectionJNI ie = new IEConnectionJNI();

try

{

ie.iePtr = ie.startFileDownload( "http://127.0.0.1:8081/big.zip", "c:\\temp\\myfile.zip", 4000 );

System.out.println("returned");

ie.new ProgressCheck(ie).start();

} catch( Exception e )

{

e.printStackTrace();

}

}

}

IEConnectionJNI.dll

JNIEXPORT jint JNICALL Java_system_IEConnectionJNI_startFileDownload( JNIEnv *env, jobject o, jstring sURL, jstring sTo, jint iTimeout )

{

const char *url = env->GetStringUTFChars( sURL, 0);

const char *to = env->GetStringUTFChars( sTo, 0 );

char *u = new char[ strlen(url) ];

char *t = new char[ strlen(to) ];

strcpy(u, url);

strcpy(t, to);

env->ReleaseStringUTFChars( sURL, url );

env->ReleaseStringUTFChars( sTo, to );

IEProgressiveConnection *ie = new IEProgressiveConnection( u, t );

ie->StartDownload();

printf("exiting jni function");

return (jint)ie;

}

JNIEXPORT jstring JNICALL Java_system_IEConnectionJNI_getDownloadStatus( JNIEnv *env, jobject o, jint ieProgressiveConnectionPtr )

{

printf("\n\ngetting status ptr\n\n");

IEProgressiveConnection *ie = (IEProgressiveConnection*)ieProgressiveConnectionPtr;

if ( ie == NULL || ie->bFinished )

{

if ( ie == NULL )

{

printf("its null");

}

else printf("not null");

printf("\n\nabout to clean up\n\n");

jclass newExcCls;

env->ExceptionDescribe();

env->ExceptionClear();

newExcCls = env->FindClass( "java/lang/Exception");

env->ThrowNew( newExcCls, "Download complete" );

// delete ie; //this line crashes app

//ie = 0; // this line on its own gets AccessViolation

//printf("\n\nshould have cleaned up....returning now\n\n");

}

jstring js;

CString status;

DWORD dwWaitResult;

dwWaitResult = WaitForSingleObject( ie->hMutex, 5000 );

switch (dwWaitResult)

{

case WAIT_OBJECT_0:

status = ie->currentStatus;

js = env->NewStringUTF(status);

ReleaseMutex(ie->hMutex);

break;

case WAIT_TIMEOUT:

case WAIT_ABANDONED:

printf("\nNeed error handling\n");

}

return js;

}

C++ Thread "IEProgressiveConnection"

void IEProgressiveConnection::StartDownload()

{

CWinThread* pWorkerThread;

pWorkerThread = AfxBeginThread ( gThreadProc, this,

THREAD_PRIORITY_NORMAL, 0,

CREATE_SUSPENDED );

printf("About to start thread\n");

pWorkerThread->ResumeThread();

printf("Not waiting\n\n");

}

UINT gThreadProc ( void* pv )

{

IEProgressiveConnection* conn = (IEProgressiveConnection*) pv;

conn->WorkerThreadProc();

return 0;

}

void IEProgressiveConnection::WorkerThreadProc()

{

...processes for about 1 minute, updating "currentStatus" using mutex, then exits, setting "bFinished" to TRUE

}

Here's the output of the above code, its a bit mixed up but I'm assuming thats due to Java getting priority over the output buffer :-

returned

got status=[Downloaded 13.4 MB of 55.6 MB,24]

got status=[Downloaded 27.3 MB of 55.6 MB,49]

got status=[Downloaded 38.0 MB of 55.6 MB,68]

got status=[Downloaded 48.6 MB of 55.6 MB,87]

java.lang.Exception: Download complete

at system.IEConnectionJNI.getDownloadStatus(Native Method)

at system.IEConnectionJNI$ProgressCheck.run(IEConnectionJNI.java:29)

About to start thread

Not waiting

exit jni function

getting status ptr

getting status ptr

getting status ptr

getting status ptr

getting status ptr

not null

about to clean up

Process finished with exit code 0

If I put in the "delete ie" line then I get the following error :-

Debug Error!

Program C:\jdk....\bin\java.exe

Damage: after Normal Block (#57) at 0x0B321910

(Press Retry.......

If I put in the "ie=0" line without the delete I get a JNI log file, containing

EXCEPTION_ACCESS_VIOLATION

I can post the whole log content if you think it will help.....however its large.

Hope this is a better post now.

knightweba at 2007-7-11 23:27:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 3

Too many work for today...

Well, at first glance I found one important issue - you doesn't allocate enough memory for strings.

char *u = new char[ strlen(url) ]; // Now

char *u = new char[ strlen(url) + 1 ]; // Should be due to terminating NULL

Correct these and check. If this will not help I'll take close look bit later.

Michael.Nazarov@sun.coma at 2007-7-11 23:27:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 4

Thanks Michael, you totally fixed it!

I changed the lines as you suggested from :-

char *u = new char[ strlen(url) ];

char *t = new char[ strlen(to) ];

to

char *u = new char[ strlen(url) + 1 ];

char *t = new char[ strlen(to) + 1 ];

And now I can delete object "ie" without crashing the app. Although if I try to then set "ie" to "0" I still get the Access Violation error......most likely I shouldn't be doing this so I've left it out.

I must admit I've no idea why your suggestion worked? Does it have something to do with my destructor in IEProgressiveConnection?.....I left this code out and some other stuff to keep my post size down.....perhaps I should post the lot!!!

IEProgressiveConnection::IEProgressiveConnection( char* url, char* to )

{

this->sURL = url;

this->sTo = to;

this->hMutex = CreateMutex(

NULL,// default security attributes

FALSE, // initially not owned

NULL);

this->bFinished=FALSE;

}

IEProgressiveConnection::~IEProgressiveConnection()

{

CloseHandle( this->hMutex );

delete [] this->sURL;

delete [] this->sTo;

}

I'd love to post all my C++ DLL code for this "IEProgressiveConnection.dll" so you could advise me on other errors you might see, but that would most likely be abusing this forum and your time.

So thanks for the fix, you got the Dukes!

knightweba at 2007-7-11 23:27:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 5

>

> And now I can delete object "ie" without crashing the

> app. Although if I try to then set "ie" to "0" I

> still get the Access Violation error......most likely

> I shouldn't be doing this so I've left it out.

Setting that to zero shouldn't cause a problem. The only way that can occur is if the stack is badly corrrupted. Because it is it suggests that you have other memory problems.

Note that best practices for inheritence hierarchies usually require virtual delete methods. Which might or might not be a problem in your case.

jschella at 2007-7-11 23:27:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 6

Hi,

Not sure how I can pinpoint the stack corruption? Here's the JNI log produce when I use "ie=0", perhaps it would mean something to you.

#

# An unexpected error has been detected by HotSpot Virtual Machine:

#

# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0afd2bb7, pid=3584, tid=1680

#

# Java VM: Java HotSpot(TM) Client VM (1.5.0_03-b07 mixed mode)

# Problematic frame:

# C [IEConnectionJNI.dll+0x2bb7]

#

T H R E A D

Current thread (0x0acc3d28): JavaThread "Thread-0" [_thread_in_native, id=1680]

siginfo: ExceptionCode=0xc0000005, reading address 0x00000010

Registers:

EAX=0x0b4cfca0, EBX=0x06c77528, ECX=0x00000000, EDX=0x0b149438

ESP=0x0b4cfc34, EBP=0x0b4cfcb0, ESI=0x0b4cfc38, EDI=0x0b4cfcb0

EIP=0x0afd2bb7, EFLAGS=0x00010246

Top of Stack: (sp=0x0b4cfc34)

0x0b4cfc34:00001388 0acc3d28 06c77520 06c77528

0x0b4cfc44:cccccccc cccccccc cccccccc cccccccc

0x0b4cfc54:cccccccc cccccccc cccccccc cccccccc

0x0b4cfc64:cccccccc cccccccc cccccccc cccccccc

0x0b4cfc74:cccccccc cccccccc cccccccc cccccccc

0x0b4cfc84:cccccccc 0b311910 cccccccc 0b311910

0x0b4cfc94:0b311910 cccccccc cccccccc 0b13d2d8

0x0b4cfca4:cccccccc 00a86770 00000000 0b4cfce0

Instructions: (pc=0x0afd2bb7)

0x0afd2ba7:f0 e8 ca 5f 0c 00 8b f4 68 88 13 00 00 8b 4d fc

0x0afd2bb7:8b 51 10 52 ff 15 b8 d3 14 0b 3b f4 e8 b8 a0 00

Stack: [0x0b490000,0x0b4d0000), sp=0x0b4cfc34, free space=255k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

C [IEConnectionJNI.dll+0x2bb7]

j system.IEConnectionJNI.getDownloadStatus(I)Ljava/lang/String;+0

j system.IEConnectionJNI$ProgressCheck.run()V+17

v ~StubRoutines::call_stub

V [jvm.dll+0x818b8]

V [jvm.dll+0xd431d]

V [jvm.dll+0x81789]

V [jvm.dll+0x814e6]

V [jvm.dll+0x9c06b]

V [jvm.dll+0xfe7f5]

V [jvm.dll+0xfe7c3]

C [MSVCRT.dll+0x2a3b0]

C [kernel32.dll+0xb683]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

j system.IEConnectionJNI.getDownloadStatus(I)Ljava/lang/String;+0

j system.IEConnectionJNI$ProgressCheck.run()V+17

v ~StubRoutines::call_stub

P R O C E S S

Java Threads: ( => current thread )

0x00037180 JavaThread "DestroyJavaVM" [_thread_blocked, id=3588]

=>0x0acc3d28 JavaThread "Thread-0" [_thread_in_native, id=1680]

0x00aca528 JavaThread "Monitor Ctrl-Break" daemon [_thread_in_native, id=3660]

0x00a92730 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=2336]

0x00a913a8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=3648]

0x00a90730 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3644]

0x00a87c18 JavaThread "Finalizer" daemon [_thread_blocked, id=3640]

0x00a86810 JavaThread "Reference Handler" daemon [_thread_blocked, id=2144]

Other Threads:

0x00a84ea8 VMThread [id=3624]

0x00a93908 WatcherThread [id=3656]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap

def new generationtotal 576K, used 378K [0x02ad0000, 0x02b70000, 0x02fb0000)

eden space 512K, 74% used [0x02ad0000, 0x02b2eb90, 0x02b50000)

from space 64K,0% used [0x02b50000, 0x02b50000, 0x02b60000)

tospace 64K,0% used [0x02b60000, 0x02b60000, 0x02b70000)

tenured generationtotal 1408K, used 0K [0x02fb0000, 0x03110000, 0x06ad0000)

the space 1408K,0% used [0x02fb0000, 0x02fb0000, 0x02fb0200, 0x03110000)

compacting perm gen total 8192K, used 1815K [0x06ad0000, 0x072d0000, 0x0aad0000)

the space 8192K, 22% used [0x06ad0000, 0x06c95e60, 0x06c96000, 0x072d0000)

No shared spaces configured.

Dynamic libraries:

0x00400000 - 0x0040c000 C:\jdk1.5.0_03\bin\java.exe

0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll

0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll

0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll

0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll

0x77c10000 - 0x77c68000 C:\WINDOWS\system32\MSVCRT.dll

0x6d6b0000 - 0x6d836000 C:\jdk1.5.0_03\jre\bin\client\jvm.dll

0x77d40000 - 0x77dd0000 C:\WINDOWS\system32\USER32.dll

0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll

0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll

0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL

0x6d2f0000 - 0x6d2f8000 C:\jdk1.5.0_03\jre\bin\hpi.dll

0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL

0x6d680000 - 0x6d68c000 C:\jdk1.5.0_03\jre\bin\verify.dll

0x6d370000 - 0x6d38d000 C:\jdk1.5.0_03\jre\bin\java.dll

0x6d6a0000 - 0x6d6af000 C:\jdk1.5.0_03\jre\bin\zip.dll

0x10000000 - 0x10007000 C:\Program Files\JetBrains\IntelliJ IDEA 6.0\bin\breakgen.dll

0x0afd0000 - 0x0b15f000 C:\projects\relatis_systray\IEConnectionJNI.dll

0x61410000 - 0x61534000 C:\WINDOWS\system32\urlmon.dll

0x774e0000 - 0x7761d000 C:\WINDOWS\system32\ole32.dll

0x77120000 - 0x771ac000 C:\WINDOWS\system32\OLEAUT32.dll

0x77f60000 - 0x77fd6000 C:\WINDOWS\system32\SHLWAPI.dll

0x5dca0000 - 0x5dce5000 C:\WINDOWS\system32\iertutil.dll

0x5d090000 - 0x5d12a000 C:\WINDOWS\system32\COMCTL32.dll

0x771b0000 - 0x7727e000 C:\WINDOWS\system32\WININET.dll

0x003f0000 - 0x003f9000 C:\WINDOWS\system32\Normaliz.dll

0x73000000 - 0x73026000 C:\WINDOWS\system32\WINSPOOL.DRV

0x763b0000 - 0x763f9000 C:\WINDOWS\system32\comdlg32.dll

0x7c9c0000 - 0x7d1d5000 C:\WINDOWS\system32\SHELL32.dll

0x773d0000 - 0x774d3000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll

0x6d530000 - 0x6d543000 C:\jdk1.5.0_03\jre\bin\net.dll

0x71ab0000 - 0x71ac7000 C:\WINDOWS\system32\WS2_32.dll

0x71aa0000 - 0x71aa8000 C:\WINDOWS\system32\WS2HELP.dll

0x77fe0000 - 0x77ff1000 C:\WINDOWS\system32\Secur32.dll

0x71a50000 - 0x71a8f000 C:\WINDOWS\system32\mswsock.dll

0x662b0000 - 0x66308000 C:\WINDOWS\system32\hnetcfg.dll

0x71a90000 - 0x71a98000 C:\WINDOWS\System32\wshtcpip.dll

0x5ad70000 - 0x5ada8000 C:\WINDOWS\system32\uxtheme.dll

0x10100000 - 0x1010e000 C:\Program Files\Logitech\SetPoint\lgscroll.dll

0x7c340000 - 0x7c396000 C:\WINDOWS\system32\MSVCR71.dll

0x7c3a0000 - 0x7c41b000 C:\WINDOWS\system32\MSVCP71.dll

0x76ee0000 - 0x76f1c000 C:\WINDOWS\system32\RASAPI32.dll

0x76e90000 - 0x76ea2000 C:\WINDOWS\system32\rasman.dll

0x5b860000 - 0x5b8b4000 C:\WINDOWS\system32\NETAPI32.dll

0x76eb0000 - 0x76edf000 C:\WINDOWS\system32\TAPI32.dll

0x76e80000 - 0x76e8e000 C:\WINDOWS\system32\rtutils.dll

0x769c0000 - 0x76a73000 C:\WINDOWS\system32\USERENV.dll

0x722b0000 - 0x722b5000 C:\WINDOWS\system32\sensapi.dll

0x76fc0000 - 0x76fc6000 C:\WINDOWS\system32\rasadhlp.dll

0x76f20000 - 0x76f47000 C:\WINDOWS\system32\DNSAPI.dll

0x76fb0000 - 0x76fb8000 C:\WINDOWS\System32\winrnr.dll

0x76f60000 - 0x76f8c000 C:\WINDOWS\system32\WLDAP32.dll

VM Arguments:

jvm_args: -Didea.launcher.port=7534 -Didea.launcher.bin.path=C:\Program Files\JetBrains\IntelliJ IDEA 6.0\bin -Dfile.encoding=windows-1252

java_command: com.intellij.rt.execution.application.AppMain system.IEConnectionJNI

Environment Variables:

CLASSPATH=.;C:\Program Files\Java\jre1.5.0_03\lib\ext\QTJava.zip

PATH=C:\oracle\product\10.2.0\db_1\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\ATI Technologies\ATI Control Panel;C:\Program Files\SecureCRT\;C:\exim_downloaded\bin;C:\BES\bin;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft Visual Studio\Common\Tools;C:\Program Files\Microsoft Visual Studio\VC98\bin;C:\BES\bin

USERNAME=Chris

OS=Windows_NT

PROCESSOR_IDENTIFIER=x86 Family 15 Model 3 Stepping 4, GenuineIntel

S Y S T E M

OS: Windows XP Build 2600 Service Pack 2

CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht

Memory: 4k page, physical 2096340k(1206824k free), swap 4194303k(3968120k free)

vm_info: Java HotSpot(TM) Client VM (1.5.0_03-b07) for windows-x86, built on Apr 13 2005 02:07:01 by "java_re" with MS VC++ 6.0

knightweba at 2007-7-11 23:27:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 7
Try to extend your C++ class with custom new and delete operators using VirtualAlloc and VirtualFree functions to allocate and destroy.
Michael.Nazarov@sun.coma at 2007-7-11 23:27:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 8
> Try to extend your C++ class with custom new and> delete operators using VirtualAlloc and VirtualFree> functions to allocate and destroy.You might want to expand on how that is going to find a memory problem (it certainly isn't clear to me.)
jschella at 2007-7-11 23:27:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 9

> Not sure how I can pinpoint the stack corruption?

Usually by carefully reviewing all of the code.

It is seldom possible to look a exception traces because it is more likely that the error occurred elsewhere and it just happens to show up where you see it.

There are free and commercial packages that provide more tools for determining memory problems in C/C++.

jschella at 2007-7-11 23:27:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 10

Thanks for the posts.

I've been over my code several times with a fine toothcomb armed with tips from various sites on common C++ memory pitfalls. But all looks to be fine.......in the sense that everything I "new or new[]" I also "delete or delete[]", and I only do so once. But yet I'm still unable to set my pointer to NULL or 0.....neither work, both cause the above "Access Violation" error.

So I took your advice jschell and looked into some memory tools....for ease of use I downloaded and setup "Visual Leak Detector" :-

http://www.codeproject.com/tools/visualleakdetector.asp

I've no idea whether this tool is any good but it certainly used lots of juice and disk time to produce the following file :-

Visual Leak Detector Version 1.9d installed.

Outputting the report to c:\projects\relatis_systray\memory_leak_report.txt

No memory leaks detected.

Visual Leak Detector is now exiting.

Is there an outside chance that because I passed this pointer to Java, that I'm not allowed to NULL the memory location? Hence the "Access Violation". Wishful thinking I know! 99.999% of the time its programmer error.

At first this was only a concern for me, general house keeping as the app runs fine. However I now need to be able to tell whether the pointer is valid or not, and the only way I know how to do this is to set it to NULL. (perhaps there is some other way)

Any thoughts?

knightweba at 2007-7-11 23:27:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 11

It isn't a matter of a leak.A leak would simply at some point (possibly) cause you to run out of memory.

Rather it is a memory problem. That means using a pointer that has been freed. Overwriting a buffer. Underwriting a buffer. Using uninitilized pointers. Using casts incorrectly. There are probably quite a few others.

jschella at 2007-7-11 23:27:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 12
> You might want to expand on how that is going to find a memory problem (it certainly isn't clear to me.)These functions are safer to use in case of transferring pointer between dll calls. It was some time ago so I just don't want to remember all details.Just trust me
Michael.Nazarov@sun.coma at 2007-7-11 23:27:05 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 13
Thanks for all the posts. Stupidly I was missing a "return NULL" after setting "ie=0", so all's sorted now.I have another question though. If I want my class to self destroy under some conditions I use "delete this;" however how do I then set "this = 0"?
knightweba at 2007-7-11 23:27:05 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 14

> Stupidly I was missing a "return NULL" after setting "ie=0", so all's sorted now.

I can't see "return NULL" in posted code. That's why one should post real code, not retyping with some omitted lines...

> however how do I then set "this = 0"?

You don't need to do so.

Michael.Nazarov@sun.coma at 2007-7-11 23:27:05 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 15

> I can't see "return NULL" in posted code. That's why

> one should post real code, not retyping with some

> omitted lines...

I did post the real code that contained the problem.The reason you can't see "return NULL" is because that was the problem, I never coded it, hence the "Access Violation".

> > however how do I then set "this = 0"?

>

> You don't need to do so.

I think I need to do this some how if possible or some other techniquie. Because I want to check later on that this pointer is no longer valid. Otherwise, my understanding is, it will still potentially point to the old object or worse still to memory that contains something else.

knightweba at 2007-7-21 19:55:58 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 16

>

> > > however how do I then set "this = 0"?

> >

> > You don't need to do so.

>

> I think I need to do this some how if possible or

> some other techniquie. Because I want to check later

> on that this pointer is no longer valid. Otherwise,

> my understanding is, it will still potentially point

> to the old object or worse still to memory that

> contains something else.

No you don't need to do it - 'this' is a real pointer. If you have other pointers then you can set them to zero.

jschella at 2007-7-21 19:55:58 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 17

> > You might want to expand on how that is going to

> find a memory problem (it certainly isn't clear to

> me.)

>

> These functions are safer to use in case of

> transferring pointer between dll calls. It was some

> time ago so I just don't want to remember all

> details.

> Just trust me :)

Let's put it slightly differently....

With 20 years of C/C++ experience and something like 15 in windows plus looking at the documentation for the specific functions that you recommended I can't see how the use of those would have any impact what so ever on the problem that the OP posted.

I also googled for any sources that might even remotely suggest that it would help with what you implied. I found nothing.

So trust me, without a detailed explanation as to how you think that is going to help, I can only believe that you don't in fact know how it will help and don't actually understand what those methods do.

But do feel free to provide a detailed explanation so I can learn the error of my ways.

jschella at 2007-7-21 19:55:58 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 18

Ah, I see. The other pointer I was trying to NULL by setting "this = NULL" was the pointer I passed to Java. Which I now realise would never have worked as it will always point to the memory space the object use to (and most likely still) occupies. I solved my dilema by calling a Java method in the class to set the pointer(int) to 0...I'm not sure if this is correct but it works for me. I can now control when this pointer becomes invalid.

Thanks for all the help.

knightweba at 2007-7-21 19:55:58 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 19

> With 20 years of C/C++ experience and something like 15 in windows

This is not real argument actually :) It's like I'm 7 feet while your are 6 so I'm better basketball player then you.

Ok, it's principal question so I'll provide source code and/or link to documentation. Hope next week or bit later because there are a lot of work here, J1 you know...

Michael.Nazarov@sun.coma at 2007-7-21 19:55:58 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 20

Unfortunately (or fortunately) HDD in my home PC failed and I have complete copy of my really old projects here at office. So I found some staff and ready to show :)

Ok here the code for allocating DLL. Hope such experienced guy will find way to compile ;) I used Intel's compiler BTW, releasing DLL without debug info. This DLL called "dll.dll". Don't forget to export functions.

There are some constants in the code - don't blame me please...

#include <windows.h>

char* VAllocate( void )

{

char* c = ( char* )VirtualAlloc( NULL, 1024, MEM_COMMIT, PAGE_READWRITE );

if( c )

strcpy( c, "Hi" );

return c;

}

char* CAllocate( void )

{

char* c = new char[ 1024 ];

if( c )

strcpy( c, "Hi" );

return c;

}

BOOL WINAPI DllMain

(

HINSTANCE hinstDLL, // handle to the DLL module

DWORD fdwReason,// reason for calling function

LPVOID lpvReserved// reserved

)

{

return TRUE;

}

Code for another one DLL. Please call this one "dll2.dll". Stupid names, I know. Feel free to use your own but correct 3-d peace of code also.

#include <windows.h>

void VFree( void* c )

{

VirtualFree( c, 0, MEM_RELEASE );

return;

}

void CFree( void* c )

{

delete [] c;

return;

}

BOOL WINAPI DllMain

(

HINSTANCE hinstDLL, // handle to the DLL module

DWORD fdwReason,// reason for calling function

LPVOID lpvReserved// reserved

)

{

return TRUE;

}

Well, the most interesting part AKA host program. Please forgive some glitches.

BTW I named executable as "mem.exe", no debug info. Just FYI.

#include <windows.h>

#include <stdio.h>

typedef char*(*lpalloc)(void);

typedef void(*lpfree)(char*);

int main( int argc, char** args )

{

if( 3 != argc )

{

printf( "agruments\n" );

return -99;

}

HMODULE hAlloc = LoadLibrary( "dll.dll" );

if( !hAlloc )

{

printf( "dll.dll\n" );

return -1;

}

lpalloc fa = ( lpalloc )GetProcAddress( hAlloc, args[ 1 ] );

if( !fa )

{

printf( "fa\n" );

return -2;

}

char* c = fa( );

if( !c )

{

printf( "c\n" );

return -3;

}

FreeLibrary( hAlloc );

HMODULE hFree = LoadLibrary( "dll2.dll" );

if( !hFree )

{

printf( "dll2\n" );

return -4;

}

lpfree ff = ( lpfree )GetProcAddress( hFree, args[ 2 ] );

if( !ff )

{

printf( "ff\n" );

return -5;

}

printf( "%s\n", c );

ff( c );

FreeLibrary( hFree );

return 0;

}

Ok, compile all staff and check. Ensure your dlls are visible to your exe.

First check is as followed:

mem.exe VAllocate VFree

Second one is:

mem.exe СAllocate СFree

Ok, for guys who doesn't know how to deal with all above. Output in first case is:

Hi

Output in second case is unpredictable, application even crashed under some conditions.

Please check and let me know result.

Ok?

Michael.Nazarov@sun.coma at 2007-7-21 19:55:58 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 21

>

> Ok, compile all staff and check.

You are using it to move memory across dll boundaries. And manage it across boundaries as well.

Which certainly has nothing to do with what the OP is doing.

And normally has nothing to do with most C/C++ programming.

Not even in applications that use dynamic loading for multiple dlls. That would be because best practices usually dictate that allocations and deallocations occur within a single scope.

You will find that if you use one dll that your program will work in both cases (precluding any other programming errors which I didn't look for.)

jschella at 2007-7-21 19:55:58 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 22

I knew you'll answer this way :)

> You are using it to move memory across dll boundaries. And manage it across boundaries as well.

Yes, I am. Because this is easiest way to create hard memory management conditions. I hope you heard about stress testing. This is it - unusual but effective and visible.

> Which certainly has nothing to do with what the OP is doing.

This has.

Anyway I said Virtual functions are safer and I provide code. No?

Also I didn't say this is 100% help OP. No?

> And normally has nothing to do with most C/C++ programming.

In your opinion only. I believe if one spent 30 years for coding text parsers using VB (ok, even C++) he might know little about pointers, dlls and safe memory management.

> You will find that if you use one dll that your program will work in both cases

Again - this is kind of show. I didn't say new/delete are bad in all situiations.

Ok, just one question: did I prove VirtualAlloc and VirtualFree are safer then simple new[] and delete[] in unusual situations?

Michael.Nazarov@sun.coma at 2007-7-21 19:55:58 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 23

> I knew you'll answer this way :)

>

> > You are using it to move memory across dll

> boundaries. And manage it across boundaries as well.

>

> Yes, I am. Because this is easiest way to create hard

> memory management conditions. I hope you heard about

> stress testing. This is it - unusual but effective

> and visible.

Sorry no.

>

> > Which certainly has nothing to do with what the OP

> is doing.

>

> This has.

> Anyway I said Virtual functions are safer and I

> provide code. No?

> Also I didn't say this is 100% help OP. No?

You provided an example that was guaranteed to fail because of the way the memory was being used.

I could do the same thing by using shared memory on any number of OSes. That however doesn't mean that everyone should give up using new in C++ and should instead switch to using shared memory methods.

>

> > And normally has nothing to do with most C/C++

> programming.

>

> In your opinion only. I believe if one spent 30 years

> for coding text parsers using VB (ok, even C++) he

> might know little about pointers, dlls and safe

> memory management.

>

I have written heap managers for C++ and C libraries. I have written numerous custom new replacements for C++ classes and system replacements as well.

So yes I know a little bit about how C/C++ memory management works.

You on the other hand don't understand how memory works in the process space for a windows application.

If you did you would understand how ridiculous your assertion is that your program "demonstrates" the problem where as using a single dll wouldn't.

There is no problem if a single dll is used.

> > You will find that if you use one dll that your

> program will work in both cases

>

> Again - this is kind of show. I didn't say new/delete

> are bad in all situiations.

>

And again what I said was.

1. It has absolutely nothing to do with the OPs problem.

2. It has absolutely nothing to do with most (probably the vast majority) of C/C++ programming.

Are you seriously claiming that you use those methods all the time in C++ programming rather than 'new'?

And if that is not your contention then why exactly do you think it is safe for you to use 'new' in the vast majority of cases where in the case of the OP it isn't safe?

>

> Ok, just one question: did I prove VirtualAlloc and

> VirtualFree are safer then simple new[] and delete[]

> in unusual situations?

I suggest you read your reply #7 again and also read the OPs postings.

You first reply has nothing to do with cross boundary issues. And the OP has absolutely no need for cross boundary memory.

jschella at 2007-7-21 19:55:58 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 24
:)All your wrote is just words: I have experience, I wrote this and I wrote that while all other understand nothing.In other hand you just did not read answers.Ok, keep you long-long experience with you.
Michael.Nazarov@sun.coma at 2007-7-21 19:55:58 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 25

> All your wrote is just words:

What are you writing - ice cream?

> I have experience, I

> wrote this and I wrote that while all other

> understand nothing.

> In other hand you just did not read answers.

As far as I am concerned the only confusion here is on your part.

And your first reply on the subject (the one to which I orginally questioned this) is just wrong. Your follow ups either demonstrate that you don't understand what the methods you are referring to should be used for or that you don't understand what the OP was doing.

>

> Ok, keep you long-long experience with you.

And that comment suggests to me that you don't have the experience to know what I am talking about.

jschella at 2007-7-21 19:55:59 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 26
You are too self-satisfied ram to keep this discussion.Usually your post correct answers but generally you are nothing but experience shaker without arguments with useless blaming only.
Michael.Nazarov@sun.coma at 2007-7-21 19:55:59 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 27

> You are too self-satisfied ram to keep this

> discussion.

Which makes no sense.

> Usually your post correct answers but generally you

> are nothing but experience shaker without arguments

> with useless blaming only.

Which only demonstrates your lack of knowledge about that as well.

I can only note this is the second time this month that you have made a factual error which I have had to correct you on.

And that error concerned C/C++ usage as well. As well as ignoring information in the OPs posting too.

jschella at 2007-7-21 19:55:59 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 28
It's only your dreams about my errors.
Michael.Nazarov@sun.coma at 2007-7-21 19:55:59 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 29
> It's only your dreams about my errors.I wish. Unfortunately it isn't. So I need to keep spending time correcting your bad information.
jschella at 2007-7-21 19:55:59 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 30
Unfortunately you use "bad information" for everything you only think is bad.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 31
Hi,Is flamming each other help Java community ?--Marc
mdentya at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 32
Sometimes yes.Not sure about this one.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 33

> Is flamming each other help Java community ?

>

Did you bother reading the posts that lead up to this?

If so feel free to comment on them.

Myself, I need to keep pointing out that the other poster is posting (for a second time) incorrect information. I do this to preclude the OP and future readers from accepting that it is some how correct or can help in any way.

If you feel my conclusions in that regard are incorrect then point how where either I failed technically or where I failed in regard to the interpretation of the verbiage (taken in light of future readers as well.)

jschella at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 34
> Unfortunately you use "bad information" for> everything you only think is bad.I pointed out specifically what was wrong with your posts.I am not really concerned with whether you understand that but whether others might be mislead by your comments.
jschella at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 35
No you did not. You just wrote that you don't like. Nothing more.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 36

> No you did not. You just wrote that you don't like.

> Nothing more.

Many people do not like inefficient memory management. That of course doesn't make it wrong. It might even work for a very long time.

That doesn't make it right either.

Presumably if you actually write C/C++ code you will some day figure out why all of those VirtualAllocs are so inefficient.

Or whoever that has to maintain your code afterward will.

jschella at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 37

> No you did not. You just wrote that you don't like.

> Nothing more.

Please use your expert knowledge to explain the output of the following code. In particular answer the following questions.

1. Why does the base address vary for the VirtualAlloc and not for the the new?

2. What impact do each of the following represent in the memory model of the application?

Please note that the code uses exactly what you posted for your solution.

#include <windows.h>

#include "stdafx.h"

void displayMemory(void* p)

{

MEMORY_BASIC_INFORMATION buffer;

memset(&buffer, 0, sizeof(buffer));

SIZE_T rtn = VirtualQuery(p, &buffer, sizeof(buffer));

if (rtn > 0)

printf("page=%p size=%i\n", buffer.BaseAddress, (int)buffer.RegionSize);

}

void testNew(const int size, const int count)

{

char** array = new char*[count];

for (int i=0; i < count; i++)

array[i] = new char[size];

printf("- test new\n");

for (int i=0; i < count; i++)

displayMemory(array[i]);

for (int i=0; i < count; i++)

delete[] array[i];

delete[] array;

}

void testVirtualAlloc(const int size, const int count)

{

char** array = new char*[count];

for (int i=0; i < count; i++)

array[i] = ( char* )VirtualAlloc( NULL, 1024, MEM_COMMIT, PAGE_READWRITE );

printf("- test virtual\n");

for (int i=0; i < count; i++)

displayMemory(array[i]);

for (int i=0; i < count; i++)

VirtualFree( array[i], 0, MEM_RELEASE );;

delete[] array;

}

int _tmain(int argc, _TCHAR* argv[])

{

displayMemory("Hello\n");

const int size=10;

const int count=3;

testNew(size, count);

testVirtualAlloc(size, count);

return 0;

}

-- Output -

page=00415000 size=8192

- test new

page=00355000 size=12288

page=00355000 size=12288

page=00355000 size=12288

- test virtual

page=00360000 size=4096

page=00370000 size=4096

page=00380000 size=4096

jschella at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 38
Please explain what "pages" are referring to in the following microsoft documentation link for VirtualAlloc. Please explain what impact "pages" have on the memory footprint/usage of an application. http://msdn2.microsoft.com/en-us/library/aa366887.aspx
jschella at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 39
I'm not interested to take exam here. Feel free to comment this like "You just have no knowledge".BTW I appreciated you efforts in attempt of testing my skills.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 40

> I'm not interested to take exam here. Feel free to

> comment this like "You just have no knowledge".

> BTW I appreciated you efforts in attempt of testing

> my skills.

Which demonstrates to me that you don't understand it.

It requires no more than a sentence or two from someone that does understand it either in detail or even just conceptually.

jschella at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 41
I know your position and already said my opinion and position about you.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 42

> I know your position and already said my opinion and

> position about you.

All I can suggest to anyone else if they come across this thread is that they learn something about modern operating systems and CPU architectures and what paging means in those systems.

And thus it will be obvious to them why they shouldn't normally be using VirtualAlloc and certainly should never use in the context of something like what the OP was doing.

jschella at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 43
As for me I suggest to everybody to learn something regardless of reading this thread.And use Virtual functions in cases like I posted.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 44

> As for me I suggest to everybody to learn something

> regardless of reading this thread.

>

> And use Virtual functions in cases like I posted.

If you need to allocate in one dll and deallocate in another then.

1. Your implementation is very likely to be wrong.

2. If it isn't wrong then one at least needs to consider the impact on application memory when one uses VirtualAlloc.

Other than that your general suggestion that VirtualAlloc can be used to solve general memory errors is wrong

jschella at 2007-7-21 19:56:04 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 45
Ok, let's start it again and again.You think it's wrong only because you think so.You know something about WinAPI but looks like it was too many time ago.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 46

> Ok, let's start it again and again.

> You think it's wrong only because

> you think so.

I know it is wrong because it is exceedingly inefficient use of memory.

And because you suggested it would fix memory problems which it won't.

> You know something about WinAPI but looks like it was

> too many time ago.

And yet you still haven't explained what the code I posted demonstrates.

jschella at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 47
Yes you know because you know and only because you know.And I'm not going to describe each code you post here because I'm not going to.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 48
> Yes you know because you know and only because you know.> And I'm not going to describe each code you post here> because I'm not going to.The reason is because you don't understand it.
jschella at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 49
You think so.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 50
> You think so.I know so - proved by your inability to explain my example code.
jschella at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 51
Looks like you are really think you are guru and everybody should answer your questions immediately... But you are not - think about this fact.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 52

> Looks like you are really think you are guru and

> everybody should answer your questions immediately...

> But you are not - think about this fact.

Think about this fact - you can't explain my example.

That should be sufficient for anyone besides you to judge competency.

jschella at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 53
I don't want - think you.Your so called "arguments" is sufficient for anyone also.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 54

> I don't want - think you.

> Your so called "arguments" is sufficient for anyone

> also.

I have been on this site for 10 years. I suspect I will be here a few more.

So feel free to continue to insist that you are "right" and I will add as many posts additionally to point out that you can't explain my example and haven't provided an explanation of what VirtualAlloc actually does.

Hopefully you have only used it to solve a dll to dll issue (which merely points out a bad design) rather than using it to fix other problems (which would mean that you hid the actual problem and so someone else will have to find the real problem.)

jschella at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 55

Wow! 10 years! So again you think some links to experience are best argumentation.

You can't understand easy things about answers but you have some knowledge - this is worst situation because you basing on your long... exp you think you know not something but everything and have right to judge.

Hope you are not manager...

And feel free to post some additional measures - say age or weight. Hopefully these fact will also be useful as "arguments". You love to compare...

Michael.Nazarov@sun.coma at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 56

> Wow! 10 years! So again you think some links to

> experience are best argumentation.

That isn't to prove my point but rather to comment on your "did" - "did not" posts which address nothing.

And that I will continue to respond each time you do.

> You can't understand easy things about answers but

> you have some knowledge - this is worst situation

> because you basing on your long... exp you think you

> know not something but everything and have right to

> judge.

I have the right to judge until you demonstrate that you know what VirtualAlloc actually does.

Explaining my example would demonstrate that.

Claiming over and over again that you are right and that I am wrong does not.

jschella at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 57
You have only rights to write your opinion nothing more.I'm already stop to claiming I'm right, I'm just watching about your answers - very interesting.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 58

> You have only rights to write your opinion nothing

> more.

Yet something on which you are incorrect.

> I'm already stop to claiming I'm right, I'm just

> watching about your answers - very interesting.

Your responses continue to insinute that my question about your use of VirtualAlloc is wrong.

If you want to admit that your usage suggestion was incorrect (which is was I pointed out) then you can then feel free to make vague insults about my character as much as you wish.

Until that happens though I will presume that you still haven't gotten the point.

jschella at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 59
As for you - please feel free to write anything about your experience and my "complete nonentity". That doesn't matter anyway but you bring me some fun and additional information about forums persons.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:09 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 60

> As for you - please feel free to write anything about

> your experience and my "complete nonentity".

That statement means nothing to me.

> That doesn't matter anyway but you bring me some fun and

> additional information about forums persons.

As do you, since I now check your posts for factual correctness.

jschella at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 61
> That statement means nothing to me.Your statements also means nothing.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 62
> > That statement means nothing to me.> > Your statements also means nothing.They, unlike yours, are factually correct.And presumably you still don't understand why your original suggestion was wrong.
jschella at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 63
As I remember I already wrote all I want but if you are going to start it again (3d or 4th time?) let's start again. You think you are correct nothing more. And you did not read my posts with care.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 64

> As I remember I already wrote all I want but if you

> are going to start it again (3d or 4th time?) let's

> start again. You think you are correct nothing more.

> And you did not read my posts with care.

I read your posts with enough care to understand that you don't know what VirtualAlloc does.

I also read them with enough care to determine that you have no interest in figuring out why your information is incorrect.

As for writing all you want, I already pointed out that I am going to keep responding as long as you do so. Or at least until you admit to your mistake (I doubt that will happen.)

You could of course explain my example code and then based on that demonstrate how your suggestion has anything to do with the OPs post. That would be defending your opinion. Versus your current responses which merely imply that I am wrong.

jschella at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 65
The next person to post is a "big smelly jobby".
knightweba at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 66
> The next person to post is a "big smelly jobby". How many years will you stay in kindergarten?
Michael.Nazarov@sun.coma at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 67
Ehh, you based on you opinion and wrong idea about you "guruism" and rights to judge. We discussed already as I remember but you keep going with "your" code... Keep it this way hopefully you'll feel better.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 68

> Ehh, you based on you opinion and wrong idea about

> you "guruism" and rights to judge.

Your advice was wrong. That is objective rather than subjective and so needs no judging.

I do however judge you on your inability to understand why it was bad and inability to learn from your mistake.

> We discussed

> already as I remember but you keep going with "your"

> code... Keep it this way hopefully you'll feel better.

I will feel better knowing that no one will use your incorrect advice.

jschella at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 69
Looks like you are in fear about me... Hope you'll get sleepless nights worrying about my posts.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 70

> Looks like you are in fear about me... Hope you'll

> get sleepless nights worrying about my posts.

You amuse me.

People who actually understand my posts are never as amusing as those that don't. And those that stubbornly resist even the suggestion that their knowledge is incorrect are the funniest of all.

Congrats on be one of the more amusing ones. I am sure you will continue to be so.

jschella at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 71
Sure I'll continue to be so while you are already. Keep going.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 72
> Sure I'll continue to be so while you are already.> Keep going.Try to be more original.
jschella at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 73
I'm not sure you'll understand complex humor.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 74
> I'm not sure you'll understand complex humor.Which is similar to your inability to explain my example code. You claim that you can deliver but never actually demonstrate that you can.
jschella at 2007-7-21 19:56:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 75
You forgot to take note about your experience, your messages looks incomplete without.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 76
> You forgot to take note about your experience, your> messages looks incomplete without.So that is your excuse for not attempting to explain my example?
jschella at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 77
i like this thread.
prob.not.sola at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 78
> i like this thread.me too; i missed the fun for quite a while.
aniseeda at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 79
> > i like this thread.> > me too; i missed the fun for quite a while.it's pretty funny to see just how arrogant jschell is.poor guy. can't admit when he's wrong.
prob.not.sola at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 80
The more I read about "your example" the more I think you just need help with code you can't understand. But you are to "experienced" to ask "Help me" instead you trying to "examine"...
Michael.Nazarov@sun.coma at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 81

> > > i like this thread.

> >

> > me too; i missed the fun for quite a while.

>

> it's pretty funny to see just how arrogant jschell

> is.

>

> poor guy. can't admit when he's wrong.

You too can feel free to explain my example.

Or educate me on how C++ code should always use VirtualAlloc for all memory allocations.

I will awaiting your next post with anticipation.

jschella at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 82
> The more I read about "your example" the more I think> you just need help with code you can't understand.> But you are to "experienced" to ask "Help me" instead> you trying to "examine"...Feel free to explain it to me then.
jschella at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 83

> > > > i like this thread.

> > >

> > > me too; i missed the fun for quite a while.

> >

> > it's pretty funny to see just how arrogant jschell

> > is.

> >

> > poor guy. can't admit when he's wrong.

>

> You too can feel free to explain my example.

>

> Or educate me on how C++ code should always use

> VirtualAlloc for all memory allocations.

>

> I will awaiting your next post with anticipation.

i don't know c++ nor did i really read your example; but i think the underlying theme is that you are taking things too literally and have no sense of humour.

prob.not.sola at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 84

> > The more I read about "your example" the more I

> think

> > you just need help with code you can't understand.

> > But you are to "experienced" to ask "Help me"

> instead

> > you trying to "examine"...

>

> Feel free to explain it to me then.

here is where you aren't quite following: nobody needs to explain anything to you.

prob.not.sola at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 85
> > Feel free to explain it to me then.> > here is where you aren't quite following: nobody> needs to explain anything to you.Yeah, what kind of an expert needs explanation of his own code. :p
aniseeda at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 86
Feel free to reread my answers.
Michael.Nazarov@sun.coma at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 87

> > I will awaiting your next post with anticipation.

>

> i don't know c++ nor did i really read your example;

> but i think the underlying theme is that you are

> taking things too literally and have no sense of

> humour.

The posted solution and the reason given for it were wrong. It could have mislead the original poster and future readers as well.

Yes, I take that seriously.

jschella at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 88

> > > Feel free to explain it to me then.

> >

> > here is where you aren't quite following: nobody

> > needs to explain anything to you.

>

> Yeah, what kind of an expert needs explanation of his

> own code. :p

It is of course used to specifically point out that the other poster doesn't know what VirtualAlloc does. If that poster could explain the output of my code then they would demonstrate that they do in fact know what VirtualAlloc does. I could even presume that if that was the case then we could proceed with an actual discussion as to why VirtualAlloc was suggested in the first place.

As it is however I can only guess that the poster "solved" a problem in the past with VirtualAlloc and now thinks it is a solution for everything. It certainly wasn't a solution for the OP and a lack of understanding makes it likely that it was used to solve another problem incorrectly.

jschella at 2007-7-21 19:56:19 > top of Java-index,Java HotSpot Virtual Machine,Specifications...