Re: [AOLSERVER] Aolserver Progress - Some few examples....
Maurizio, Tcl_Finalize() is supposed to work, and if it does now work something is still broken in the windows version. Omitting Tcl_Finalize() is removeing the symptom, not the cause. It is not unlikely that something else will have the same problem due to this cause. When Tcl_Finalize() is not run, the registered exit handlers are not executed. How serious this is depends on the exit handlers. You are right, that the memory leak does not matter due to the shutdown. The difference is like between a graceful and an ungraceful shutdown. -gustaf On 05.08.11 16:29, Maurizio Martignano wrote: Dear Gustav, I understand your concerns about Tcl_Finalize... but it is called just when the process/service is about to end. Once it ends the OS takes charges and releases the process/service resources (memory included). You can make an easy test Have Aolserver / nsd running on a big application... observe the OS resources given to the process and released when I finishes. Do this twice: with Tcl_Finalize on and Tcl_Finalize commented out. And see if you can find any difference. Ciao, Maurizio -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Aolserver Progress - Some few examples....
Dear Gustav, I understand perfectly than omitting the function is removing the symptom and not the cause, but process/service wise having Tcl_Finalize in that particular place (where the process/service is about to end) or not having it doesn't make any difference. The Operating System will take care of all resources de-allocation. Nevertheless, exactly for the reason you mentioned, that there may be some problems and that these problems may not be present only in that particular piece of code, I'll have a look into the function behavior. I suspect that it might be a matter of the order with which things are de-allocated. but I might be wrong. I'll come back on this. Thank you for your point, I will follow your recommendation. Ciao, Maurizio From: AOLserver Discussion [mailto:AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Gustaf Neumann Sent: 06 August 2011 10:28 To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] Aolserver Progress - Some few examples Maurizio, Tcl_Finalize() is supposed to work, and if it does now work something is still broken in the windows version. Omitting Tcl_Finalize() is removeing the symptom, not the cause. It is not unlikely that something else will have the same problem due to this cause. When Tcl_Finalize() is not run, the registered exit handlers are not executed. How serious this is depends on the exit handlers. You are right, that the memory leak does not matter due to the shutdown. The difference is like between a graceful and an ungraceful shutdown. -gustaf On 05.08.11 16:29, Maurizio Martignano wrote: Dear Gustav, I understand your concerns about Tcl_Finalize. but it is called just when the process/service is about to end. Once it ends the OS takes charges and releases the process/service resources (memory included). You can make an easy test.. Have Aolserver / nsd running on a big application. observe the OS resources given to the process and released when I finishes. Do this twice: with Tcl_Finalize on and Tcl_Finalize commented out. And see if you can find any difference. Ciao, Maurizio -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Aolserver Progress - Some few examples....
YES. I do agree that executing or not executing the exit handlers may make a difference.. Just to help me in my troubleshooting can you tell me if and where these handlers are registered. I am digging into Tcl_Finalize.. J Thank you, Maurizio From: AOLserver Discussion [mailto:AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Gustaf Neumann Sent: 06 August 2011 10:28 To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] Aolserver Progress - Some few examples Maurizio, Tcl_Finalize() is supposed to work, and if it does now work something is still broken in the windows version. Omitting Tcl_Finalize() is removeing the symptom, not the cause. It is not unlikely that something else will have the same problem due to this cause. When Tcl_Finalize() is not run, the registered exit handlers are not executed. How serious this is depends on the exit handlers. You are right, that the memory leak does not matter due to the shutdown. The difference is like between a graceful and an ungraceful shutdown. -gustaf On 05.08.11 16:29, Maurizio Martignano wrote: Dear Gustav, I understand your concerns about Tcl_Finalize. but it is called just when the process/service is about to end. Once it ends the OS takes charges and releases the process/service resources (memory included). You can make an easy test.. Have Aolserver / nsd running on a big application. observe the OS resources given to the process and released when I finishes. Do this twice: with Tcl_Finalize on and Tcl_Finalize commented out. And see if you can find any difference. Ciao, Maurizio -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Aolserver Progress - Some few examples....
It is me again. Well I noticed that the change I suggested about Tcl_Finalize did not make it into CVS HEAD. If it doesn't go there, I am afraid I will have to anyhow introduce it myself in my distribution. I need to have a working system. With that call still in, the service can't (CANNOT) be stopped gracefully. This is a matter of testing: Take the system, make it run with a real OpenACS based application (how about ]po[, or xowiki..) and see how it works and see how it interacts with the system. Does it start? Does it run? Does it stop properly? For the time being in Windows 64 that function needs to be out. Thanks a lot, Maurizio Thank you, Maurizio From: AOLserver Discussion [mailto:AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Gustaf Neumann Sent: 06 August 2011 10:28 To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] Aolserver Progress - Some few examples Maurizio, Tcl_Finalize() is supposed to work, and if it does now work something is still broken in the windows version. Omitting Tcl_Finalize() is removeing the symptom, not the cause. It is not unlikely that something else will have the same problem due to this cause. When Tcl_Finalize() is not run, the registered exit handlers are not executed. How serious this is depends on the exit handlers. You are right, that the memory leak does not matter due to the shutdown. The difference is like between a graceful and an ungraceful shutdown. -gustaf On 05.08.11 16:29, Maurizio Martignano wrote: Dear Gustav, I understand your concerns about Tcl_Finalize. but it is called just when the process/service is about to end. Once it ends the OS takes charges and releases the process/service resources (memory included). You can make an easy test.. Have Aolserver / nsd running on a big application. observe the OS resources given to the process and released when I finishes. Do this twice: with Tcl_Finalize on and Tcl_Finalize commented out. And see if you can find any difference. Ciao, Maurizio -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Aolserver Progress - Some few examples....
Dear Dossy,
Your proposal of your wrapper sounds good to me.
Why do not we insert that in the codebase? Till we understand better the
issue?
Next week I am going to redo some testing also in Win32 and I will let you
know..
Thank you very much,
Maurizio
From: AOLserver Discussion [mailto:AOLSERVER@LISTSERV.AOL.COM] On Behalf Of
Dossy Shiobara
Sent: 06 August 2011 17:39
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] Aolserver Progress - Some few examples
Could you build AOLserver with debugging symbols and run nsd.exe under a
debugger, with Tcl_Finalize *NOT* commented out/removed (i.e., as it
currently is in CVS HEAD) and confirm where this 0x4015 exception is
actually happening?
Not calling Tcl_Finalize at process exit means any callbacks registered with
Tcl_CreateExitHandler will not fire. It is absolutely wrong to not call
Tcl_Finalize for this reason.
If this is causing a problem on Win64 at the moment, as a temporary measure,
you could wrap the call to Tcl_Finalize with the appropriate #ifndef:
#if !defined(_WIN64)
Tcl_Finalize();
#endif // !_WIN64
But, on all other platforms where invoking Tcl_Finalize does work, it should
absolutely be done.
On 8/6/11 9:35 AM, Maurizio Martignano wrote:
Dear Gustav (and all the others)
I did some digging.
And here are the results..
1. Tcl_Finalize gets properly called in Windows 64 by tclsh (ok
tlcsh85t.exe) at exit time
2. From within Aolserver it doesn't even get actually called, but at
the act of calling an exception is generated inside the C/C++ runtime:
Faulting application name: nsd.exe, version: 0.0.0.0, time stamp: 0x4e3d1e32
Faulting module name: MSVCR100.dll, version: 10.0.30319.415, time stamp:
0x4d26d15a
Exception code: 0x4015
Fault offset: 0x00075fe9
Faulting process id: 0x1114
Faulting application start time: 0x01cc542b82cdba6b
Faulting application path: C:\aolserver\bin\nsd.exe
Faulting module path: C:\Windows\system32\MSVCR100.dll
Report Id: e90de38e-c01e-11e0-9d90-cef6f702c08b
3. Looking at the code in TCL I believe (and here I repeat I BELIEVE)
the problem is in the TCL DLL initialization code:
tclWin32Dll.c
case DLL_PROCESS_DETACH:
/*
* Protect the call to Tcl_Finalize. The OS could be unloading us from
* an exception handler and the state of the stack might be unstable.
*/
if defined(HAVE_NO_SEH) !defined(_WIN64)
__asm__ __volatile__ (
/*
* Construct an EXCEPTION_REGISTRATION to protect the call to
* Tcl_Finalize
*/
leal %[registration], %%edx \n\t
movl %%fs:0, %%eax\n\t
movl %%eax,0x0(%%edx) \n\t /* link */
leal 1f, %%eax\n\t
movl %%eax,0x4(%%edx) \n\t /* handler */
movl %%ebp,0x8(%%edx) \n\t /* ebp */
movl %%esp,0xc(%%edx) \n\t /* esp */
movl %[error], 0x10(%%edx) \n\t /* status */
/*
* Link the EXCEPTION_REGISTRATION on the chain
*/
movl %%edx,%%fs:0 \n\t
/*
* Call Tcl_Finalize
*/
call _Tcl_Finalize\n\t
/*
* Come here on a normal exit. Recover the EXCEPTION_REGISTRATION
* and store a TCL_OK status
*/
movl %%fs:0, %%edx\n\t
movl %[ok],%%eax\n\t
movl %%eax,0x10(%%edx) \n\t
jmp2f \n
/*
* Come here on an exception. Get the EXCEPTION_REGISTRATION that
* we previously put on the chain.
*/
1:\t
movl %%fs:0, %%edx\n\t
movl 0x8(%%edx), %%edx\n
/*
* Come here however we exited. Restore context from the
* EXCEPTION_REGISTRATION in case the stack is unbalanced.
*/
2:\t
movl 0xc(%%edx), %%esp\n\t
movl 0x8(%%edx), %%ebp\n\t
movl 0x0(%%edx), %%eax\n\t
movl %%eax,%%fs:0 \n\t
:
/* No outputs */
:
[registration] m (registration),
[ok] i (TCL_OK),
[error] i (TCL_ERROR)
:
%eax, %ebx, %ecx, %edx, %esi, %edi, memory
);
#else
#ifndef HAVE_NO_SEH
__try {
#endif
Tcl_Finalize();
#ifndef HAVE_NO_SEH
} __except (EXCEPTION_EXECUTE_HANDLER) {
/* empty handler body. */
}
#endif
#endif
break
4. My personal point of view
a. This portion of code is too target specific, it uses assembly, some
of these things may become obsolete or wrong when for instance moving
Re: [AOLSERVER] Aolserver Progress - Some few examples.... - Errata Corrige
Hello all I did some tests on Windows 32. Tcl_Finalize prevents the proper stopping of the service also on Windows 32. So the proper mod was and still is: // Conditional compilation clause added by M. Martignano on the 05/08/2011 #ifndef _WIN32 Tcl_Finalize(); #endif Tcl_Finalize doesn't work also on the 32 bit code. Ciao, Maurizio Dear Dossy, Your proposal of your wrapper sounds good to me. Why do not we insert that in the codebase? Till we understand better the issue? Next week I am going to redo some testing also in Win32 and I will let you know.. Thank you very much, Maurizio From: AOLserver Discussion [mailto:AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Dossy Shiobara Sent: 06 August 2011 17:39 To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] Aolserver Progress - Some few examples Could you build AOLserver with debugging symbols and run nsd.exe under a debugger, with Tcl_Finalize *NOT* commented out/removed (i.e., as it currently is in CVS HEAD) and confirm where this 0x4015 exception is actually happening? Not calling Tcl_Finalize at process exit means any callbacks registered with Tcl_CreateExitHandler will not fire. It is absolutely wrong to not call Tcl_Finalize for this reason. If this is causing a problem on Win64 at the moment, as a temporary measure, you could wrap the call to Tcl_Finalize with the appropriate #ifndef: #if !defined(_WIN64) Tcl_Finalize(); #endif // !_WIN64 But, on all other platforms where invoking Tcl_Finalize does work, it should absolutely be done. On 8/6/11 9:35 AM, Maurizio Martignano wrote: Dear Gustav (and all the others) I did some digging. And here are the results.. 1. Tcl_Finalize gets properly called in Windows 64 by tclsh (ok tlcsh85t.exe) at exit time 2. From within Aolserver it doesn't even get actually called, but at the act of calling an exception is generated inside the C/C++ runtime: Faulting application name: nsd.exe, version: 0.0.0.0, time stamp: 0x4e3d1e32 Faulting module name: MSVCR100.dll, version: 10.0.30319.415, time stamp: 0x4d26d15a Exception code: 0x4015 Fault offset: 0x00075fe9 Faulting process id: 0x1114 Faulting application start time: 0x01cc542b82cdba6b Faulting application path: C:\aolserver\bin\nsd.exe Faulting module path: C:\Windows\system32\MSVCR100.dll Report Id: e90de38e-c01e-11e0-9d90-cef6f702c08b 3. Looking at the code in TCL I believe (and here I repeat I BELIEVE) the problem is in the TCL DLL initialization code: tclWin32Dll.c case DLL_PROCESS_DETACH: /* * Protect the call to Tcl_Finalize. The OS could be unloading us from * an exception handler and the state of the stack might be unstable. */ if defined(HAVE_NO_SEH) !defined(_WIN64) __asm__ __volatile__ ( /* * Construct an EXCEPTION_REGISTRATION to protect the call to * Tcl_Finalize */ leal %[registration], %%edx \n\t movl %%fs:0, %%eax\n\t movl %%eax,0x0(%%edx) \n\t /* link */ leal 1f, %%eax\n\t movl %%eax,0x4(%%edx) \n\t /* handler */ movl %%ebp,0x8(%%edx) \n\t /* ebp */ movl %%esp,0xc(%%edx) \n\t /* esp */ movl %[error], 0x10(%%edx) \n\t /* status */ /* * Link the EXCEPTION_REGISTRATION on the chain */ movl %%edx,%%fs:0 \n\t /* * Call Tcl_Finalize */ call _Tcl_Finalize\n\t /* * Come here on a normal exit. Recover the EXCEPTION_REGISTRATION * and store a TCL_OK status */ movl %%fs:0, %%edx\n\t movl %[ok],%%eax\n\t movl %%eax,0x10(%%edx) \n\t jmp2f \n /* * Come here on an exception. Get the EXCEPTION_REGISTRATION that * we previously put on the chain. */ 1:\t movl %%fs:0, %%edx\n\t movl 0x8(%%edx), %%edx\n /* * Come here however we exited. Restore context from the * EXCEPTION_REGISTRATION in case the stack is unbalanced. */ 2:\t movl 0xc(%%edx), %%esp\n\t movl 0x8(%%edx), %%ebp\n\t movl 0x0(%%edx), %%eax\n\t movl %%eax,%%fs:0 \n\t : /* No outputs */ : [registration] m (registration), [ok] i (TCL_OK), [error] i (TCL_ERROR) : %eax, %ebx, %ecx, %edx, %esi, %edi, memory ); #else
Re: [AOLSERVER] Aolserver Progress - Some few examples.... - Errata Corrige
I vaguely remember never figuring this out either and deciding to ifdef it out. In practice it doesn't do much -- I've never come across a on-exit handler that really needed fire. Curious if anyone has. Jim Sent from a phone On Aug 6, 2011, at 3:29 PM, Maurizio Martignano maurizio.martign...@spazioit.com wrote: Hello all I did some tests on Windows 32. Tcl_Finalize prevents the proper stopping of the service also on Windows 32. So the proper mod was and still is: // Conditional compilation clause added by M. Martignano on the 05/08/2011 #ifndef _WIN32 Tcl_Finalize(); #endif Tcl_Finalize doesn’t work also on the 32 bit code. Ciao, Maurizio Dear Dossy, Your proposal of your wrapper sounds good to me. Why do not we insert that in the codebase? Till we understand better the issue? Next week I am going to redo some testing also in Win32 and I will let you know…. Thank you very much, Maurizio From: AOLserver Discussion [mailto:AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Dossy Shiobara Sent: 06 August 2011 17:39 To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] Aolserver Progress - Some few examples Could you build AOLserver with debugging symbols and run nsd.exe under a debugger, with Tcl_Finalize *NOT* commented out/removed (i.e., as it currently is in CVS HEAD) and confirm where this 0x4015 exception is actually happening? Not calling Tcl_Finalize at process exit means any callbacks registered with Tcl_CreateExitHandler will not fire. It is absolutely wrong to not call Tcl_Finalize for this reason. If this is causing a problem on Win64 at the moment, as a temporary measure, you could wrap the call to Tcl_Finalize with the appropriate #ifndef: #if !defined(_WIN64) Tcl_Finalize(); #endif // !_WIN64 But, on all other platforms where invoking Tcl_Finalize does work, it should absolutely be done. On 8/6/11 9:35 AM, Maurizio Martignano wrote: Dear Gustav (and all the others) I did some digging… And here are the results…. 1. Tcl_Finalize gets properly called in Windows 64 by tclsh (ok tlcsh85t.exe) at exit time 2. From within Aolserver it doesn’t even get actually called, but at the act of calling an exception is generated inside the C/C++ runtime: Faulting application name: nsd.exe, version: 0.0.0.0, time stamp: 0x4e3d1e32 Faulting module name: MSVCR100.dll, version: 10.0.30319.415, time stamp: 0x4d26d15a Exception code: 0x4015 Fault offset: 0x00075fe9 Faulting process id: 0x1114 Faulting application start time: 0x01cc542b82cdba6b Faulting application path: C:\aolserver\bin\nsd.exe Faulting module path: C:\Windows\system32\MSVCR100.dll Report Id: e90de38e-c01e-11e0-9d90-cef6f702c08b 3. Looking at the code in TCL I believe (and here I repeat I BELIEVE) the problem is in the TCL DLL initialization code: tclWin32Dll.c case DLL_PROCESS_DETACH: /* * Protect the call to Tcl_Finalize. The OS could be unloading us from * an exception handler and the state of the stack might be unstable. */ if defined(HAVE_NO_SEH) !defined(_WIN64) __asm__ __volatile__ ( /* * Construct an EXCEPTION_REGISTRATION to protect the call to * Tcl_Finalize */ leal %[registration], %%edx \n\t movl %%fs:0, %%eax\n\t movl %%eax,0x0(%%edx) \n\t /* link */ leal 1f, %%eax\n\t movl %%eax,0x4(%%edx) \n\t /* handler */ movl %%ebp,0x8(%%edx) \n\t /* ebp */ movl %%esp,0xc(%%edx) \n\t /* esp */ movl %[error], 0x10(%%edx) \n\t /* status */ /* * Link the EXCEPTION_REGISTRATION on the chain */ movl %%edx,%%fs:0 \n\t /* * Call Tcl_Finalize */ call _Tcl_Finalize\n\t /* * Come here on a normal exit. Recover the EXCEPTION_REGISTRATION * and store a TCL_OK status */ movl %%fs:0, %%edx\n\t movl %[ok],%%eax\n\t movl %%eax,0x10(%%edx) \n\t jmp2f \n /* * Come here on an exception. Get the EXCEPTION_REGISTRATION that * we previously put on the chain. */ 1:\t movl %%fs:0, %%edx\n\t movl 0x8(%%edx), %%edx\n /* * Come here however we exited. Restore context
