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 0x40000015 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: 0x40000015 Fault offset: 0x0000000000075fe9 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" "jmp 2f" "\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 from a version of the compiler to a newer one. b. I do not have neither the energy nor the time to try to fix this code (this would require a strong interaction with the TCL community. ) c. All of this would be a lot of effort with practically no added value whatsoever, considering where/where Tcl_Finalize is called from within Aolserver 5. My personal recommendation a. I would just accept the change/the mod I suggested to remove the call to this function from Aolserver for Windows 32 and 64. b. If not, and only until this issue gets somehow resolved, I will keep still this function commented out in my Windows-OpenACS distribution. Ciao, 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 <mailto:lists...@listserv.aol.com> <lists...@listserv.aol.com> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. -- Dossy Shiobara | "He realized the fastest way to change do...@panoptic.com | is to laugh at your own folly -- then you http://panoptic.com/ | can let go and quickly move on." (p. 70) * WordPress * jQuery * MySQL * Security * Business Continuity * -- 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.