Menu
▾
▴
naviserver-devel
|
From: Andrew P. <at...@pi...> - 2014-10-03 12:49:26
|
With my changes here, the core Naviserver compiles now on my Windows 7 64-bit machine: https://bitbucket.org/naviserver/naviserver/pull-requests https://bitbucket.org/apiskors/naviserver/commits/all However, it doesn't work at all. If I simply run "nsd -h", it hangs indefinitely, and locks up the Command Prompt window where I ran nsd. Control-c does not abort, I have to close the window. Note that I built Naviserver using ActiveTcl 8.5, I did not compile Tcl myself. I just started learning to use the WinDbg debugger. Below is a stack trace. This one is from attaching WinDbg to an already-running "nsd.exe -h" process, but it looks the same if I intead tell WinDbg to run nsd.exe itself (with no command line arguments) . >From the stack trace, Naviserver seems to be getting stuck when Ns_GetTime (line 69 of time.c) calls TclpGetDate. But, line 69 does not explicitly call TclpGetDate, it justs manipulates a Tcl_Time tbuf structure like so: timePtr->sec = tbuf.sec; In Tcl 8.5.x, TclpGetDate is in win/tclWinTime.c, but the string "TclpGetDate" does not occur anywhere in the Naviserver code, so I'm not sure how it manages to call it. A function pointer somewhere? Any ideas what might be wrong here, or what else I should do to debug this further? Here the initial WinDbg output when attaching to a running "nsd.exe -h" process, and then the stack trace (the "k" command): ------------------------------------------------------------ *** wait with pending attach Symbol search path is: C:\web\nsd-atp\lib;http://msdl.microsoft.com/download/symbols Executable search path is: ModLoad: 00000001`3f080000 00000001`3f0fe000 C:\web\nsd-atp\bin\nsd.exe ModLoad: 00000000`775e0000 00000000`77789000 C:\Windows\SYSTEM32\ntdll.dll ModLoad: 00000000`773c0000 00000000`774df000 C:\Windows\system32\kernel32.dll ModLoad: 000007fe`fd430000 000007fe`fd49c000 C:\Windows\system32\KERNELBASE.dll ModLoad: 000007fe`f0680000 000007fe`f0828000 C:\web\nsd-atp\bin\nsd.dll ModLoad: 000007fe`faab0000 000007fe`fab4e000 C:\web\nsd-atp\bin\nsthread.dll ModLoad: 00000000`10000000 00000000`100dc000 C:\P\Tcl85\bin\tcl85.dll ModLoad: 00000000`774e0000 00000000`775da000 C:\Windows\system32\USER32.dll ModLoad: 000007fe`fdd40000 000007fe`fdda7000 C:\Windows\system32\GDI32.dll ModLoad: 000007fe`ff8e0000 000007fe`ff8ee000 C:\Windows\system32\LPK.dll ModLoad: 000007fe`ff470000 000007fe`ff539000 C:\Windows\system32\USP10.dll ModLoad: 000007fe`ff2e0000 000007fe`ff37f000 C:\Windows\system32\msvcrt.dll ModLoad: 000007fe`ff380000 000007fe`ff45b000 C:\Windows\system32\ADVAPI32.dll ModLoad: 000007fe`fdad0000 000007fe`fdaef000 C:\Windows\SYSTEM32\sechost.dll ModLoad: 000007fe`ff780000 000007fe`ff8ad000 C:\Windows\system32\RPCRT4.dll ModLoad: 000007fe`fee00000 000007fe`fee4d000 C:\Windows\system32\WS2_32.dll ModLoad: 000007fe`ff460000 000007fe`ff468000 C:\Windows\system32\NSI.dll ModLoad: 000007fe`ff8b0000 000007fe`ff8de000 C:\Windows\system32\IMM32.DLL ModLoad: 000007fe`fd9c0000 000007fe`fdac9000 C:\Windows\system32\MSCTF.dll Break-in sent, waiting 30 seconds... WARNING: Break-in timed out, suspending. This is usually caused by another thread holding the loader lock (e98.12c): Wake debugger - code 80000007 (first chance) ntdll!ZwWaitForSingleObject+0xa: 00000000`776312fa c3 ret 0:000> kc Call Site ntdll!ZwWaitForSingleObject *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\P\Tcl85\bin\tcl85.dll - KERNELBASE!WaitForSingleObjectEx *** WARNING: Unable to verify checksum for C:\web\nsd-atp\bin\nsthread.dll tcl85!TclpGetDate [...] 0:000> k Child-SP RetAddr Call Site 00000000`0027eeb8 000007fe`fd4310dc ntdll!ZwWaitForSingleObject+0xa 00000000`0027eec0 00000000`100a4766 KERNELBASE!WaitForSingleObjectEx+0x79 00000000`0027ef60 000007fe`faab4139 tcl85!TclpGetDate+0x5c2 00000000`0027efc0 000007fe`faab1bf6 nsthread!Ns_GetTime+0x29 [z:\web\ns-fork\naviserver\nsthread\time.c @ 69] 00000000`0027f010 000007fe`faab25f9 nsthread!Ns_MutexLock+0x76 [z:\web\ns-fork\naviserver\nsthread\mutex.c @ 210] 00000000`0027f0d0 000007fe`faab144a nsthread!Ns_CsEnter+0x69 [z:\web\ns-fork\naviserver\nsthread\cslock.c @ 172] 00000000`0027f110 000007fe`faab3db8 nsthread!Ns_MasterLock+0x2a [z:\web\ns-fork\naviserver\nsthread\master.c @ 71] 00000000`0027f140 000007fe`faab2c58 nsthread!Ns_TlsAlloc+0x28 [z:\web\ns-fork\naviserver\nsthread\tls.c @ 77] 00000000`0027f180 000007fe`faab33d2 nsthread!NsInitReentrant+0x28 [z:\web\ns-fork\naviserver\nsthread\reentrant.c @ 65] 00000000`0027f1b0 000007fe`faab4514 nsthread!NsInitThreads+0x32 [z:\web\ns-fork\naviserver\nsthread\thread.c @ 105] 00000000`0027f1e0 000007fe`faab457d nsthread!Nsthreads_LibInit+0x44 [z:\web\ns-fork\naviserver\nsthread\winthread.c @ 132] 00000000`0027f210 000007fe`faabddf0 nsthread!DllMain+0x5d [z:\web\ns-fork\naviserver\nsthread\winthread.c @ 164] 00000000`0027f250 000007fe`faabdd41 nsthread!__DllMainCRTStartup+0xa0 [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\dllcrt0.c @ 330] 00000000`0027f2a0 00000000`7761b108 nsthread!_DllMainCRTStartup+0x31 [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\dllcrt0.c @ 294] 00000000`0027f2d0 00000000`77621e5a ntdll!LdrpRunInitializeRoutines+0x1fe 00000000`0027f4a0 00000000`77621937 ntdll!LdrpInitializeProcess+0x1b8a 00000000`0027f990 00000000`7760c34e ntdll! ?? ::FNODOBFM::`string'+0x28ff0 00000000`0027fa00 00000000`00000000 ntdll!LdrInitializeThunk+0xe -- Andrew Piskorski <at...@pi...> |
|
From: Maurizio M. <Mau...@sp...> - 2014-10-03 13:21:19
|
Dear Andrew, Did you happen to use this define _USE_32BIT_TIME_T? Hope it helps, Maurizio -----Original Message----- From: Andrew Piskorski [mailto:at...@pi...] Sent: 03 October 2014 14:49 To: nav...@li... Subject: [naviserver-devel] Naviserver hangs on Windows With my changes here, the core Naviserver compiles now on my Windows 7 64-bit machine: https://bitbucket.org/naviserver/naviserver/pull-requests https://bitbucket.org/apiskors/naviserver/commits/all However, it doesn't work at all. If I simply run "nsd -h", it hangs indefinitely, and locks up the Command Prompt window where I ran nsd. Control-c does not abort, I have to close the window. Note that I built Naviserver using ActiveTcl 8.5, I did not compile Tcl myself. I just started learning to use the WinDbg debugger. Below is a stack trace. This one is from attaching WinDbg to an already-running "nsd.exe -h" process, but it looks the same if I intead tell WinDbg to run nsd.exe itself (with no command line arguments) . >From the stack trace, Naviserver seems to be getting stuck when Ns_GetTime (line 69 of time.c) calls TclpGetDate. But, line 69 does not explicitly call TclpGetDate, it justs manipulates a Tcl_Time tbuf structure like so: timePtr->sec = tbuf.sec; In Tcl 8.5.x, TclpGetDate is in win/tclWinTime.c, but the string "TclpGetDate" does not occur anywhere in the Naviserver code, so I'm not sure how it manages to call it. A function pointer somewhere? Any ideas what might be wrong here, or what else I should do to debug this further? Here the initial WinDbg output when attaching to a running "nsd.exe -h" process, and then the stack trace (the "k" command): ------------------------------------------------------------ *** wait with pending attach Symbol search path is: C:\web\nsd-atp\lib;http://msdl.microsoft.com/download/symbols Executable search path is: ModLoad: 00000001`3f080000 00000001`3f0fe000 C:\web\nsd-atp\bin\nsd.exe ModLoad: 00000000`775e0000 00000000`77789000 C:\Windows\SYSTEM32\ntdll.dll ModLoad: 00000000`773c0000 00000000`774df000 C:\Windows\system32\kernel32.dll ModLoad: 000007fe`fd430000 000007fe`fd49c000 C:\Windows\system32\KERNELBASE.dll ModLoad: 000007fe`f0680000 000007fe`f0828000 C:\web\nsd-atp\bin\nsd.dll ModLoad: 000007fe`faab0000 000007fe`fab4e000 C:\web\nsd-atp\bin\nsthread.dll ModLoad: 00000000`10000000 00000000`100dc000 C:\P\Tcl85\bin\tcl85.dll ModLoad: 00000000`774e0000 00000000`775da000 C:\Windows\system32\USER32.dll ModLoad: 000007fe`fdd40000 000007fe`fdda7000 C:\Windows\system32\GDI32.dll ModLoad: 000007fe`ff8e0000 000007fe`ff8ee000 C:\Windows\system32\LPK.dll ModLoad: 000007fe`ff470000 000007fe`ff539000 C:\Windows\system32\USP10.dll ModLoad: 000007fe`ff2e0000 000007fe`ff37f000 C:\Windows\system32\msvcrt.dll ModLoad: 000007fe`ff380000 000007fe`ff45b000 C:\Windows\system32\ADVAPI32.dll ModLoad: 000007fe`fdad0000 000007fe`fdaef000 C:\Windows\SYSTEM32\sechost.dll ModLoad: 000007fe`ff780000 000007fe`ff8ad000 C:\Windows\system32\RPCRT4.dll ModLoad: 000007fe`fee00000 000007fe`fee4d000 C:\Windows\system32\WS2_32.dll ModLoad: 000007fe`ff460000 000007fe`ff468000 C:\Windows\system32\NSI.dll ModLoad: 000007fe`ff8b0000 000007fe`ff8de000 C:\Windows\system32\IMM32.DLL ModLoad: 000007fe`fd9c0000 000007fe`fdac9000 C:\Windows\system32\MSCTF.dll Break-in sent, waiting 30 seconds... WARNING: Break-in timed out, suspending. This is usually caused by another thread holding the loader lock (e98.12c): Wake debugger - code 80000007 (first chance) ntdll!ZwWaitForSingleObject+0xa: 00000000`776312fa c3 ret 0:000> kc Call Site ntdll!ZwWaitForSingleObject *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\P\Tcl85\bin\tcl85.dll - KERNELBASE!WaitForSingleObjectEx *** WARNING: Unable to verify checksum for C:\web\nsd-atp\bin\nsthread.dll tcl85!TclpGetDate [...] 0:000> k Child-SP RetAddr Call Site 00000000`0027eeb8 000007fe`fd4310dc ntdll!ZwWaitForSingleObject+0xa 00000000`0027eec0 00000000`100a4766 KERNELBASE!WaitForSingleObjectEx+0x79 00000000`0027ef60 000007fe`faab4139 tcl85!TclpGetDate+0x5c2 00000000`0027efc0 000007fe`faab1bf6 nsthread!Ns_GetTime+0x29 [z:\web\ns-fork\naviserver\nsthread\time.c @ 69] 00000000`0027f010 000007fe`faab25f9 nsthread!Ns_MutexLock+0x76 [z:\web\ns-fork\naviserver\nsthread\mutex.c @ 210] 00000000`0027f0d0 000007fe`faab144a nsthread!Ns_CsEnter+0x69 [z:\web\ns-fork\naviserver\nsthread\cslock.c @ 172] 00000000`0027f110 000007fe`faab3db8 nsthread!Ns_MasterLock+0x2a [z:\web\ns-fork\naviserver\nsthread\master.c @ 71] 00000000`0027f140 000007fe`faab2c58 nsthread!Ns_TlsAlloc+0x28 [z:\web\ns-fork\naviserver\nsthread\tls.c @ 77] 00000000`0027f180 000007fe`faab33d2 nsthread!NsInitReentrant+0x28 [z:\web\ns-fork\naviserver\nsthread\reentrant.c @ 65] 00000000`0027f1b0 000007fe`faab4514 nsthread!NsInitThreads+0x32 [z:\web\ns-fork\naviserver\nsthread\thread.c @ 105] 00000000`0027f1e0 000007fe`faab457d nsthread!Nsthreads_LibInit+0x44 [z:\web\ns-fork\naviserver\nsthread\winthread.c @ 132] 00000000`0027f210 000007fe`faabddf0 nsthread!DllMain+0x5d [z:\web\ns-fork\naviserver\nsthread\winthread.c @ 164] 00000000`0027f250 000007fe`faabdd41 nsthread!__DllMainCRTStartup+0xa0 [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\dllcrt0.c @ 330] 00000000`0027f2a0 00000000`7761b108 nsthread!_DllMainCRTStartup+0x31 [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\dllcrt0.c @ 294] 00000000`0027f2d0 00000000`77621e5a ntdll!LdrpRunInitializeRoutines+0x1fe 00000000`0027f4a0 00000000`77621937 ntdll!LdrpInitializeProcess+0x1b8a 00000000`0027f990 00000000`7760c34e ntdll! ?? ::FNODOBFM::`string'+0x28ff0 00000000`0027fa00 00000000`00000000 ntdll!LdrInitializeThunk+0xe -- Andrew Piskorski <at...@pi...> ---------------------------------------------------------------------------- -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ naviserver-devel mailing list nav...@li... https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Andrew P. <at...@pi...> - 2014-10-03 13:58:05
|
On Fri, Oct 03, 2014 at 03:21:02PM +0200, Maurizio Martignano wrote: > Dear Andrew, > Did you happen to use this define _USE_32BIT_TIME_T? No, I did not. Should I? Does Tcl use that? Grepping my source files, I see this: ./include/nsconfig.h:276:#define SIZEOF_TIME_T 8 That nsconfig.h was created on Linux, but my Windows build uses it too. Perhaps that is the problem? But how the heck can I generate a correct version of nsconfig.h for my Windows 7 system? -- Andrew Piskorski <at...@pi...> |
|
From: Maurizio M. <Mau...@sp...> - 2014-10-03 14:10:13
|
Well I do not know... What is your target? W32 or W64? What is your target machine? E.g. X64? or AMD? How do you link the DLL? Maurizio -----Original Message----- From: Andrew Piskorski [mailto:at...@pi...] Sent: 03 October 2014 15:58 To: nav...@li... Subject: Re: [naviserver-devel] Naviserver hangs on Windows On Fri, Oct 03, 2014 at 03:21:02PM +0200, Maurizio Martignano wrote: > Dear Andrew, > Did you happen to use this define _USE_32BIT_TIME_T? No, I did not. Should I? Does Tcl use that? Grepping my source files, I see this: ./include/nsconfig.h:276:#define SIZEOF_TIME_T 8 That nsconfig.h was created on Linux, but my Windows build uses it too. Perhaps that is the problem? But how the heck can I generate a correct version of nsconfig.h for my Windows 7 system? -- Andrew Piskorski <at...@pi...> ---------------------------------------------------------------------------- -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ naviserver-devel mailing list nav...@li... https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Maurizio M. <Mau...@sp...> - 2014-10-03 14:16:57
|
Dear Andrew, These are the basic options I would use for a Windows 64 bit, AMD64: COPTS = /EHsc /W3 /nologo /c DEFS = $(DEFS) /D "_WINDOWS" /D "TCL_THREADS=1" /D "WIN32" /D "_WIN32" \ /D "FD_SETSIZE=128" /D "NO_CONST=1" /D "_MBCS" # /D "_USE_32BIT_TIME_T" LOPTS = /NOLOGO /SUBSYSTEM:CONSOLE /OPT:NOREF /OPT:NOICF Hope it helps, Maurizio -----Original Message----- From: Andrew Piskorski [mailto:at...@pi...] Sent: 03 October 2014 15:58 To: nav...@li... Subject: Re: [naviserver-devel] Naviserver hangs on Windows On Fri, Oct 03, 2014 at 03:21:02PM +0200, Maurizio Martignano wrote: > Dear Andrew, > Did you happen to use this define _USE_32BIT_TIME_T? No, I did not. Should I? Does Tcl use that? Grepping my source files, I see this: ./include/nsconfig.h:276:#define SIZEOF_TIME_T 8 That nsconfig.h was created on Linux, but my Windows build uses it too. Perhaps that is the problem? But how the heck can I generate a correct version of nsconfig.h for my Windows 7 system? -- Andrew Piskorski <at...@pi...> ---------------------------------------------------------------------------- -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ naviserver-devel mailing list nav...@li... https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Andrew P. <at...@pi...> - 2014-10-07 18:51:23
|
On Fri, Oct 03, 2014 at 04:16:41PM +0200, Maurizio Martignano wrote: > Dear Andrew, > These are the basic options I would use for a Windows 64 bit, AMD64: > > COPTS = /EHsc /W3 /nologo /c > DEFS = $(DEFS) /D "_WINDOWS" /D "TCL_THREADS=1" /D "WIN32" /D "_WIN32" \ > /D "FD_SETSIZE=128" /D "NO_CONST=1" /D "_MBCS" # /D "_USE_32BIT_TIME_T" > LOPTS = /NOLOGO /SUBSYSTEM:CONSOLE /OPT:NOREF /OPT:NOICF Did you comment out your _USE_32BIT_TIME_T there? What does "/D _WIN32" do? What C run-time library are you using? I've been able to find Microsoft docs on the various compiler and linker flags, but NOT anything clear on what all the magic /D preprocessor definitions actually do. The nmake files I got from Ibrahim (at Archiware) use the "/MTd" compiler flag, which should give me the debug version of the "libcmtd.lib" CRT, as explained here: http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.100%29.aspx http://msdn.microsoft.com/en-us/library/2kzt1wy3%28v=vs.100%29.aspx The other main option is /MDd for "msvcrtd.lib", but I don't know which is the default when you pass no flags at all. Most of our other build options are the same. However, besides the ones I mentioned above, I am also using these extra flags that you do not have: In COPTS: /Zi /RTC1 In DEFS: /D _CRT_SECURE_NO_WARNINGS /D _CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE /D "_DEBUG" In LOPTS: /DEBUG AFAICT those all just enable additional debugging and/or run-time checks, and so should be pretty safe. -- Andrew Piskorski <at...@pi...> |
|
From: Andrew P. <at...@pi...> - 2014-10-03 14:49:34
|
Hm, the old AOLserver 4.0.7 version of Ns_GetTime() had a Windows
ifdef which is entirely missing from Naviserver! (See below.)
I found two relevant commits in Mercurial, from 2009 and 2012, below.
>From those logs, it looks like what happened is that in 2009, Zoran
removed the platform specific C code and instead made Naviserver call
Tcl_GetTime (somehow). Then in 2012, Gustaf added back the old
Unix-specific gettimeofday() implementation for performance reasons.
So should we just add back the old Windows-specific C implementation
too? Or is it better to use Zoran's way of invoking Tcl_GetTime? Do
we even know for sure if that method really is "platform-independent"
as Zoran thought it was? E.g., did Zoran or someone else at Archiware
test it on Windows?
Part of Ns_GetTime() from ancient AOLserver 4.0.7 sources:
------------------------------------------------------------
#ifdef _WIN32
/*
* Number of 100 nanosecond units from 1/1/1601 to 1/1/1970
*/
#define EPOCH_BIAS 116444736000000000i64
union {
unsigned __int64 i;
FILETIME s;
} ft;
GetSystemTimeAsFileTime(&ft.s);
timePtr->sec = (time_t)((ft.i - EPOCH_BIAS) / 10000000i64);
timePtr->usec =(long)((ft.i / 10i64) % 1000000i64);
#else
#endif
changeset: 2435:16508ab4b3de
user: Gustaf Neumann <ne...@wu...>
date: Fri Nov 02 01:54:38 2012 +0100
files: configure.in include/nsconfig.h.in nsthread/time.c
description:
use gettimeofday() if available instead of the rount trip to tcl
changeset: 2009:4bf1ee6ebf84
user: Zoran Vasiljevic <zv...@ar...>
date: Sat Sep 29 14:14:03 2007 +0100
files: ChangeLog nsproxy/nsproxylib.c nsthread/time.c
description:
Ns_GetTime now relies on Tcl_GetTime to be platform-independent
--
Andrew Piskorski <at...@pi...>
|
|
From: Andrew P. <at...@pi...> - 2014-10-04 10:59:56
|
On Fri, Oct 03, 2014 at 10:49:27AM -0400, Andrew Piskorski wrote: > Hm, the old AOLserver 4.0.7 version of Ns_GetTime() had a Windows > ifdef which is entirely missing from Naviserver! (See below.) I added back that Windows-specific Ns_GetTime() here: https://bitbucket.org/apiskors/naviserver/commits/51f1735d788d7b00adc797a7579272763ddd9bcf With that change, "nsd -h" started working, but running nsd with any other arguments now stops with a Windows pop-up box saying: Debug Assertion Failed! File: f:\dd\vctools\crt_bld\self_64_amd64\crt\src\strftime.c Line: 615 Expression: ((timeptr->tm_mday >= 1) && (timeptr->tm_mday <= 31)) Mysteriously, with that new next problem I can't seem to get any plausible backtrace out of WinDbg. However, strftime() only appears three times in the entire Naviserver codebase, so I very strongly suspect that it's actually hitting that assertion in LogTime() (in nsd/log.c). So in LogTime(), I added some simple printf's just before calling strftime(). ptm->tm_mday and all the other struct members have a value of -1. That's because in ns_localtime(), localtime_s() returns an EINVAL = 22 "Invalid argument" error code, and then sets all the members to -1. http://msdn.microsoft.com/en-us/library/a442x3ye.aspx The *tp and *clock values look like a correct time_t count of seconds since the Unix epoch. So perhaps something is wrong with the only other argument ther to localtime_s(): &tlsPtr->ltbuf But what? Any ideas? -- Andrew Piskorski <at...@pi...> |
|
From: Maurizio M. <Mau...@sp...> - 2014-10-04 14:34:23
|
Again, What is your target? Windows 32 or Windows 64? Did you use the define _USE_32BIT_TIME_T yes or not? Thank you, Maurizio -----Original Message----- From: Andrew Piskorski [mailto:at...@pi...] Sent: 04 October 2014 13:00 To: nav...@li... Subject: Re: [naviserver-devel] Naviserver hangs on Windows On Fri, Oct 03, 2014 at 10:49:27AM -0400, Andrew Piskorski wrote: > Hm, the old AOLserver 4.0.7 version of Ns_GetTime() had a Windows > ifdef which is entirely missing from Naviserver! (See below.) I added back that Windows-specific Ns_GetTime() here: https://bitbucket.org/apiskors/naviserver/commits/51f1735d788d7b00adc797a757 9272763ddd9bcf With that change, "nsd -h" started working, but running nsd with any other arguments now stops with a Windows pop-up box saying: Debug Assertion Failed! File: f:\dd\vctools\crt_bld\self_64_amd64\crt\src\strftime.c Line: 615 Expression: ((timeptr->tm_mday >= 1) && (timeptr->tm_mday <= 31)) Mysteriously, with that new next problem I can't seem to get any plausible backtrace out of WinDbg. However, strftime() only appears three times in the entire Naviserver codebase, so I very strongly suspect that it's actually hitting that assertion in LogTime() (in nsd/log.c). So in LogTime(), I added some simple printf's just before calling strftime(). ptm->tm_mday and all the other struct members have a value of -1. That's because in ns_localtime(), localtime_s() returns an EINVAL = 22 "Invalid argument" error code, and then sets all the members to -1. http://msdn.microsoft.com/en-us/library/a442x3ye.aspx The *tp and *clock values look like a correct time_t count of seconds since the Unix epoch. So perhaps something is wrong with the only other argument ther to localtime_s(): &tlsPtr->ltbuf But what? Any ideas? -- Andrew Piskorski <at...@pi...> ---------------------------------------------------------------------------- -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ naviserver-devel mailing list nav...@li... https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Andrew P. <at...@pi...> - 2014-10-05 17:47:25
|
On Sat, Oct 04, 2014 at 04:07:27PM +0200, Maurizio Martignano wrote: > What is your target? Windows 32 or Windows 64? Windows 7, 64-bit. > Did you use the define _USE_32BIT_TIME_T yes or not? No I did not. -- Andrew Piskorski <at...@pi...> |
|
From: Maurizio M. <Mau...@sp...> - 2014-10-05 19:37:57
|
I believe you should use it. Thank you, Maurizio -----Original Message----- From: Andrew Piskorski [mailto:at...@pi...] Sent: 05 October 2014 19:47 To: nav...@li... Cc: Maurizio Martignano Subject: Re: [naviserver-devel] Naviserver hangs on Windows On Sat, Oct 04, 2014 at 04:07:27PM +0200, Maurizio Martignano wrote: > What is your target? Windows 32 or Windows 64? Windows 7, 64-bit. > Did you use the define _USE_32BIT_TIME_T yes or not? No I did not. -- Andrew Piskorski <at...@pi...> |
|
From: Andrew P. <at...@pi...> - 2014-10-06 21:18:16
|
On Sun, Oct 05, 2014 at 09:37:39PM +0200, Maurizio Martignano wrote: > > Did you use the define _USE_32BIT_TIME_T yes or not? > I believe you should use it. I haven't tried using _USE_32BIT_TIME_T yet, but I think using it would be INCORRECT on Windows-64. Tcl 8.5.16 does this in win/tclWinPort.h: #ifndef _WIN64 /* See [Bug 3354324]: file mtime sets wrong time */ # define _USE_32BIT_TIME_T #endif So it does NOT set _USE_32BIT_TIME_T when _WIN64 is defined. I assume _WIN64 is always defined for 64-bit Windows. Relevant discussion appears to be here: http://sourceforge.net/p/tcl/bugs/4845/ http://sourceforge.net/p/tcl/bugs/5115/ http://sourceforge.net/p/mingw/bugs/1973/ It looks to me like the horrible confusion about what should be done is only for ** 32-bit ** Windows systems, especially when trying to support multiple old and new versions of 32-bit Windows. In contrast, 64-bit Windows seems straightforward. And I am on 64-bit Windows now! So I think I should simply NEVER set "_USE_32BIT_TIME_T". Does that sound right? What does Tcl actually do, in practice, on 64-bit Linux and Window? Here's a simple test, which shows that Tcl 8.5.x does indeed use a 64-bit time_t in both those cases, and that the integer values are exactly the same on Windows and Linux, as they should be. That corresponds to my understanding of the code above, that Tcl NEVER sets _USE_32BIT_TIME_T on 64-bit Windows. # On Windows 7 64-bit, running ActiveTcl 8.5: % info patchlevel 8.5.15 % info nameofexecutable C:/P/Tcl85/bin/tclsh85.exe % info sharedlibextension .dll % set in_l [list {1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT} {9999-12-01 00:00:00 GMT}] {1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT} {9999-12-01 00:00:00 GMT} % foreach ss $in_l { set tt [clock scan $ss] ; puts "$tt -> [clock format $tt -gmt 1]" } 0 -> Thu Jan 01 00:00:00 GMT 1970 2174774400 -> Wed Dec 01 00:00:00 GMT 2038 253399622400 -> Wed Dec 01 00:00:00 GMT 9999 % exit # On Linux 64-bit, Ubuntu 12.04.3 LTS: $ /usr/bin/tclsh8.5 % info patchlevel 8.5.11 % info nameofexecutable /usr/bin/tclsh8.5 % info sharedlibextension .so % set in_l [list {1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT} {9999-12-01 00:00:00 GMT}] {1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT} {9999-12-01 00:00:00 GMT} % foreach ss $in_l { set tt [clock scan $ss] ; puts "$tt -> [clock format $tt -gmt 1]" } 0 -> Thu Jan 01 00:00:00 GMT 1970 2174774400 -> Wed Dec 01 00:00:00 GMT 2038 253399622400 -> Wed Dec 01 00:00:00 GMT 9999 % exit -- Andrew Piskorski <at...@pi...> |
|
From: Andrew P. <at...@pi...> - 2014-10-07 20:35:41
|
On Mon, Oct 06, 2014 at 05:18:08PM -0400, Andrew Piskorski wrote: > On Sun, Oct 05, 2014 at 09:37:39PM +0200, Maurizio Martignano wrote: > > > Did you use the define _USE_32BIT_TIME_T yes or not? > I haven't tried using _USE_32BIT_TIME_T yet, but I think using it > would be INCORRECT on Windows-64. If I do pass the "/D _USE_32BIT_TIME_T" flag, I get this: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\crtdefs.h(463) : fatal error C1189: #error : You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 So that seems pretty clear, I must NOT set that flag. -- Andrew Piskorski <at...@pi...> |
|
From: Gustaf N. <ne...@wu...> - 2014-10-05 19:31:45
|
Am 03.10.14 16:49, schrieb Andrew Piskorski: > I found two relevant commits in Mercurial, from 2009 and 2012, below. > >From those logs, it looks like what happened is that in 2009, Zoran > removed the platform specific C code and instead made Naviserver call > Tcl_GetTime (somehow). Then in 2012, Gustaf added back the old > Unix-specific gettimeofday() implementation for performance reasons. no, i did NOT "add back the old Unix-specific gettimeofday() implementation". What i did was to extend "configure" to look, if there is gettimeofday() available on the system. If it is, it bypasses the call to Tcl_GetTime() to get the timestamp via system call. On busy systems, Ns_GetTime() is one of the most frequent calls, used e.g. for mutex timings, so this makes a difference. The advantage of using Tcl_GetTime() is to delegate system dependencies to Tcl. What does this tell us for your situation: a) you have most probably not HAVE_GETTIMEOFDAY defined in your installation, otherwise you have an unresolved external. So, you were not at all affected by this change of mine! b) When Tcl_GetTime() is not working on your system than you have a broken Tcl installation. Does this happen with your self-compiled tcl version? In some later mail, you wrote: > ./include/nsconfig.h:276:#define SIZEOF_TIME_T 8 > > That nsconfig.h was created on Linux, but my Windows build uses it > too. Perhaps that is the problem? But how the heck can I generate a > correct version of nsconfig.h for my Windows 7 system? I have not checked the details of your changes, but as a background: If one compiles naviserver with -DHAVE_CONFIG_H (the normal case under unix-like systems), then ./include/nsconfig.h is used. For MSVC is a set minimal set of hard-coded replacement defines included, which might or might not be incomplete or requires win7 or 64bit changes. If you are including ./include/nsconfig.h (generated under linux) under windows, then you are doomed. > So in LogTime(), I added some simple printf's just before calling > strftime(). ptm->tm_mday and all the other struct members have a > value of -1. That's because in ns_localtime(), localtime_s() returns > an EINVAL = 22 "Invalid argument" error code, and then sets all the > members to -1. > >http://msdn.microsoft.com/en-us/library/a442x3ye.aspx > > The *tp and *clock values look like a correct time_t count of seconds > since the Unix epoch. So perhaps something is wrong with the only > other argument ther to localtime_s(): &tlsPtr->ltbuf The page you are citing contains the error conditions, when EINVAL is returned. The first argument can't be NULL, so clock must be invalid according to this information. you might check for testing localtime() as a replacement, but read as well in the manpage aboutUSE_32BIT_TIME_T http://msdn.microsoft.com/en-us/library/bf12f0hc.aspx I am not familiar with the TIME_T mess under windows, check as well the endless discussions on http://sourceforge.net/p/mingw/bugs/1973/?page=0 on this issue. Have you tried the suggestion of Maurizio concerning USE_32BIT_TIME_T? -g |
|
From: Jeff R. <dv...@di...> - 2014-10-06 04:47:01
Attachments:
tt.c
|
Gustaf Neumann wrote: > What i did was to extend "configure" to look, if there is gettimeofday() > available > on the system. If it is, it bypasses the call to Tcl_GetTime() to get > the timestamp > via system call. On busy systems, Ns_GetTime() is one of the most > frequent calls, used e.g. for mutex timings, so this makes a difference. > > The advantage of using Tcl_GetTime() is to delegate system dependencies > to Tcl. This struck me as an interesting optimization question, so I wrote a quick program to test it (attached). The only test environment at the moment I have is a linux VPS, so there's bound to be random influences from virtualization and whatever else happens to be running on the host at the time, so the noise is high. Still, I was not able to see any clear difference between gettimeofday(), Ns_GetTime, and Tcl_GetTime - on any given run any of the three was equally likely to be fastest. time-int the program reports typically 2:1 system time:user time. What this suggests to me is that - at least in my environment - the probable few hundred cycles difference in the implementations is completely lost to syscall and timeslice overhead or possibly cache line flushes, and it's not worth spending too much time worrying about it. I'd be interested to hear anyone else's results and interpretations, or suggestions about how to better measure the differences in these. -J |
|
From: Gustaf N. <ne...@wu...> - 2014-10-06 09:01:13
|
Am 06.10.14 06:46, schrieb Jeff Rogers: > > This struck me as an interesting optimization question, so I wrote a > quick program to test it (attached). This is not an interesting optimization question, since Tcl itself uses gettimeofday() (plus jumping around which might have a bad cache and locality influence, and some more copying). One cannot expect a big difference. For better reliability, i've increased the count. Below are 4 runs on openacs.org. The native call is from 8% to 20% faster (the latter one most probably due to external influences). The machine is a bare metal. Numbers will vary depending on the OS. The faster the system function gettimeofday() is, the bigger is the percentage difference. -g gustafn@openacs:~$ ./tt count: 100000000 Tcl_GetTime: 3858686 usec 0.04 per Ns_GetTime: 3811593 usec 0.04 per gettimeofday: 3561367 usec 0.04 per gustafn@openacs:~$ ./tt count: 100000000 Tcl_GetTime: 3858657 usec 0.04 per Ns_GetTime: 3824398 usec 0.04 per gettimeofday: 3563398 usec 0.04 per gustafn@openacs:~$ ./tt count: 100000000 Tcl_GetTime: 4351765 usec 0.04 per Ns_GetTime: 4024717 usec 0.04 per gettimeofday: 3594736 usec 0.04 per gustafn@openacs:~$ ./tt count: 100000000 Tcl_GetTime: 3864511 usec 0.04 per Ns_GetTime: 3831866 usec 0.04 per gettimeofday: 3541932 usec 0.04 per |
|
From: Andrew P. <at...@pi...> - 2014-10-06 18:15:10
|
On Sun, Oct 05, 2014 at 09:31:31PM +0200, Gustaf Neumann wrote: > On busy systems, Ns_GetTime() is one of the most > frequent calls, used e.g. for mutex timings, so this makes a difference. Yes, so it's better for performance reasons, like I said. You may have written that small paragraph of code from scratch, but it is still true that inside the ifdef you added, the code calling gettimeofday() is essentially identical to what AOLserver used for many years. This is all fine, I see no problems with that code. > What i did was to extend "configure" to look, if there is gettimeofday() Actually, and strangely, my Naviserver on Windows appeared to NEVER call gettimeofday() there, regardless of whether HAVE_GETTIMEOFDAY was true or false! I tried it both ways. I can't explain that; perhaps I was merely confused. But what is much more important to me, is that running the final "portable" Tcl-dependent code at the end definitely triggered a serious bug, making Naviserver unusable. > b) When Tcl_GetTime() is not working on your system than you have a > broken Tcl installation. Does this happen with your self-compiled tcl version? I do not know whether Tcl_GetTime() is working correctly in ActiveTcl 8.5 on Windows 7 64-bit or not. I will try something to verify that. Right now all I can say for sure is that funny indirect way that Naviserver calls Tcl_GetTime() in Ns_GetTime() fails horribly on my Windows build. So far I've never compiled Tcl on Windows 7 myself. I may try that soon to help with the debugging, but so far I've been exclusing using ActiveTcl 8.5. I strongly suspect that ActiveTcl is compiled correctly, but perhaps I am somehow linking against it incorrectly, or using incompatible build options, or something like that. > >http://msdn.microsoft.com/en-us/library/a442x3ye.aspx > > > > The *tp and *clock values look like a correct time_t count of seconds > > since the Unix epoch. So perhaps something is wrong with the only > > other argument ther to localtime_s(): &tlsPtr->ltbuf > > The page you are citing contains the error conditions, when EINVAL > is returned. The first argument can't be NULL, so clock must be > invalid according to this information. No, the clock value is not invalid, I already checked that and it is a correct count of seconds since the Unix epoch. The problem must lie either in the other argument, or in something entirely separate and out of band (e.g., build options). > on this issue. Have you tried the suggestion of Maurizio concerning > > USE_32BIT_TIME_T? I have not tried using it yet, but maybe I should. Previously, I wasn't sure if Maurizio was recommending it or warning against it. (I see now that he recommends using it.) My previous experience with AOLserver 4.0.x on Windows was with 32-bit Windows, which would have natively used 32-bit time_t. So perhaps forcing my 64-bit build to use 32-bit time_t would be useful. -- Andrew Piskorski <at...@pi...> |
|
From: Gustaf N. <ne...@wu...> - 2014-10-06 21:31:32
|
On 06.10.14 20:15, Andrew Piskorski wrote:. > Actually, and strangely, my Naviserver on Windows appeared to NEVER > call gettimeofday() there, regardless of whether HAVE_GETTIMEOFDAY was > true or false! I tried it both ways. I can't explain that; perhaps I > was merely confused. Actually, the acronym coming out of configure is #ifdef HAVE_GETTIMEOFDAY ... #endif Note that the expression is true, no matter whether HAVE_GETTIMEOFDAY is set to 1 or 0 ... was that maybe the problem? > But what is much more important to me, is that running the final > "portable" Tcl-dependent code at the end definitely triggered a > serious bug, making Naviserver unusable. The word "unusable" is a understatement. The problem here is, when the tcl library does not work, most likely other calls to the tcl library will probably fail as well. Maybe the problem is that functions of the tcl library are called to early, before it is initialized. I've merged in your changes to the main branch. In order to keep your change history, i merged the changes rather than copying the files, but had at the end the problem to get rid the branch "clean", since mercurial likes to keep branches around. when for the clock value for localtime_s() is valid, then the only problem might be the storage area, which is coming from the thread-local storage. Maybe localtime_s is not happy with the provided address. Switching the localtime() might work, but is only a fix for the symptoms. -g |
|
From: Andrew P. <at...@pi...> - 2014-10-06 21:54:11
|
On Mon, Oct 06, 2014 at 11:31:27PM +0200, Gustaf Neumann wrote: > I've merged in your changes to the main branch. In order to keep > your change history, i merged the changes rather than copying the > files, but had at the end the problem to get rid the branch "clean", > since mercurial likes to keep branches around. Is my "clean" branch helpful to you, or should I get rid of it? I created that "clean" branch with that idea that you'd prefer to merge from it rather than from my "default" branch. But I'm new to Mercurial and not entirely sure how useful that really is. What I wanted is to have my "clean" branch be almost exactly the same as my "default", but with any Andy-specific hacks removed. So I branched clean, and then removed my rpath hack. (As we've previously discussed, I need that rpath hack to work on Linux, but it's clearly the wrong fix. I added it only because I don't understand where the true bug is coming from.) In Mercurial, it doesn't seem that easy to keep two branches SLIGHTLY different from each other. Apparently the recommended way to "cherry pick" changes is with "hg graft", but I did not try that, as it didn't seem like what I really wanted in this case. I'll see how it goes as I do more merges across my two branches, assuming I keep the "clean" branch around. -- Andrew Piskorski <at...@pi...> |
|
From: Gustaf N. <ne...@wu...> - 2014-10-06 22:09:48
|
On 06.10.14 23:54, Andrew Piskorski wrote: > Is my "clean" branch helpful to you, or should I get rid of it? on the clone used for the pull request, it is easier, if no new branches are introduced (at least for me). Please something more to try: to provide some potential evidence for my "too early for tcl calls" hypothesis, i've deactivated for the time being the mutex time monitoring for windows, since the earliest calls are from mutex calls. Can you check when possible, whether Tcl_GetTime() can be used now inside Ns_GetTime()? -g |
|
From: Andrew P. <at...@pi...> - 2014-10-08 05:14:55
|
On Tue, Oct 07, 2014 at 12:09:41AM +0200, Gustaf Neumann wrote: > Please something more to try: to provide some potential evidence for > my "too early for tcl calls" hypothesis, i've deactivated for the > time being the mutex time monitoring for windows, since the earliest > calls are from mutex calls. Can you check when possible, whether > Tcl_GetTime() can be used now inside Ns_GetTime()? Gustaf, I think you were on to something there. In my fork I turned the Windows mutex timings back on, because they work now. However, they ONLY work correctly when Ns_GetTime() is using the old-style AOLserver code with EPOCH_BIAS, etc. If I change Ns_GetTime() back to using the Ns_GetTimeFromTcl() "platform-independent" code, then the server immediately hangs on startup in TclpGetDate(), just like in my original email on 10/3. To summarize, there seem to be two combinations that work ok (so far): 1. Ns_GetTime() uses EPOCH_BIAS calculation, normal mutex timings in nsthread/mutex.c turned on. 2. Ns_GetTime() uses Ns_GetTimeFromTcl(), mutex timings in nsthread/mutex.c DISABLED. With either of those combinations, Naviserver will start up and then shut down, which is really all I've tested. -- Andrew Piskorski <at...@pi...> |
|
From: Gustaf N. <ne...@wu...> - 2014-10-08 07:33:07
|
Andrew, these are good news!
the advantage of approach 2 (disable mutex timings, use ) is that this
works for 32bit and 64 bit, while (1)
works most likely only for 64bit (if i look at the constant). The
mutex timings is an additional feature in naviserver, so at least
for the time being, one can life without that.... and with the
deeper knowledge, we might be able to activate this later again.
The problem seems to be: DllMain() calls certain functions
before the normal entry point main() is called, which initializes
tcl etc. The Windows man page [1] says:
* Warning* There are serious limits on what you can do in a DLL entry
point.
... not without a reason. It seems, that nn the windows side, one
has to be very careful, what is called inside these routines, since
all calls to Tcl* are potentially unsafe.
> changing the Ns_Time.sec (in nsthread.h) to be time_t rather than long
> fixes nearly everything.
The reason, naviserver uses 2x long in Ns_Time is probably due to
Tcl, using:
typedef struct Tcl_Time {
long sec; /* Seconds. */
long usec; /* Microseconds. */
} Tcl_Time;
So at least, when using Tcl_GetTime(),
which returns the time as Tcl_Time, everything should be
fine. Note, that in your native time implementation, you
assign to timePtr->sec with (time_t), which might be
part of the problem you are experiencing.
I have to look at this closer before i have a better seeing
of consequences of changing the types in Ns_Time, i would
certainly prefer to stick to the Tcl conventions, since we depend
strongly on tcl behavior all over the place.
Probably, i should get a windows installation running, but
the setup costs are quite high in terms of time and lack
on windows-knowlege on my side.
All together, things look already much better.
-g
[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx
Am 08.10.14 07:14, schrieb Andrew Piskorski:
> On Tue, Oct 07, 2014 at 12:09:41AM +0200, Gustaf Neumann wrote:
>
>> Please something more to try: to provide some potential evidence for
>> my "too early for tcl calls" hypothesis, i've deactivated for the
>> time being the mutex time monitoring for windows, since the earliest
>> calls are from mutex calls. Can you check when possible, whether
>> Tcl_GetTime() can be used now inside Ns_GetTime()?
> Gustaf, I think you were on to something there.
>
> In my fork I turned the Windows mutex timings back on, because they
> work now. However, they ONLY work correctly when Ns_GetTime() is
> using the old-style AOLserver code with EPOCH_BIAS, etc.
>
> If I change Ns_GetTime() back to using the Ns_GetTimeFromTcl()
> "platform-independent" code, then the server immediately hangs on
> startup in TclpGetDate(), just like in my original email on 10/3.
>
> To summarize, there seem to be two combinations that work ok (so far):
>
> 1. Ns_GetTime() uses EPOCH_BIAS calculation, normal mutex timings in
> nsthread/mutex.c turned on.
>
> 2. Ns_GetTime() uses Ns_GetTimeFromTcl(), mutex timings in
> nsthread/mutex.c DISABLED.
>
> With either of those combinations, Naviserver will start up and then
> shut down, which is really all I've tested.
>
--
Univ.Prof. Dr. Gustaf Neumann
WU Vienna
Institute of Information Systems and New Media
Welthandelsplatz 1, A-1020 Vienna, Austria
|
|
From: Gustaf N. <ne...@wu...> - 2014-10-08 11:49:07
|
> I have to look at this closer before i have a better seeing > of consequences of changing the types in Ns_Time, i would > certainly prefer to stick to the Tcl conventions, since we > depend > strongly on tcl behavior all over the place. There was a bug in log.c passing the argument to ns_localtime, which shows up only on machines where sizeof(long) != sizeof(time_t). This is obviously the case for the 64bit windows build. With that fix, i would assume that the currently committed version works now on windows (with mutex timings and win-platform-specific Ns_GetTime deactivated) as far as the version with the modified Ns_Time structure. -g |
|
From: Maurizio M. <Mau...@sp...> - 2014-10-08 16:51:57
|
Dear Andrew and Gustaf,
In due time, when you both are confident on the status of Naviserver
on Windows, I would try it inside my Windows-OpenACS distribution.
First of all I would try it in few installations running on the machines I
have in my offices, then once I see it they are running fine and everything
I have now still behave the same, I would make the new version of the
distribution available.
Is that OK with you?
Maurizio
-----Original Message-----
From: Andrew Piskorski [mailto:at...@pi...]
Sent: 08 October 2014 18:39
To: nav...@li...
Subject: Re: [naviserver-devel] Naviserver hangs on Windows
On Wed, Oct 08, 2014 at 09:32:56AM +0200, Gustaf Neumann wrote:
> the advantage of approach 2 (disable mutex timings, use ) is that
> this works for 32bit and 64 bit, while (1) works most likely only for
> 64bit (if i look at the constant).
No, I'm confident that the approach using EPOCH_BIAS works just fine on
32-bit Windows, because in AOLserver 4.0.7 and 4.0.8 that is the ONLY
implementation of Ns_GetTime on Windows, and I ran those versions of
AOLserver for years on Windows XP 32-bit.
Calls to Ns_GetTime() are very common, so AFAICT, for those AOLservers to
work at all, that EPOCH_BIAS code had to be working fine on 32-bit Windows
XP. The only other alternative is that AOLserver was somehow magically
calling an entirely different function instead of Ns_GetTime(), which I
judge as very unlikely.
> The mutex timings is an additional feature in naviserver, so at least
> for the time being, one can life without that.... and with the deeper
> knowledge, we might be able to activate this later again.
Ah, I didn't realize that. I should turn them back off for Windows in my
fork then?
> The problem seems to be: DllMain() calls certain functions before the
> normal entry point main() is called, which initializes tcl etc. The
> Windows man page [1] says:
Interesting. And of course DllMain() only exists on Windows. But, why do
we need DllMain() at all? I assume we DO need it of course, I just don't
understand the design differences between Naviserver's pthread and winthread
support. Both Posix and Windows use Nsthreads_LibInit(), but DllMain()
seems to be an extra layer not present for Posix.
> > changing the Ns_Time.sec (in nsthread.h) to be time_t rather than
> long > fixes nearly everything.
>
> The reason, naviserver uses 2x long in Ns_Time is probably due to Tcl,
> using:
AFAICT, using long is just wrong, and Tcl and Naviserver both should have
been using time_t for many years now. I'm not sure when time_t was invented
and standardized, but since then it's been what Unix and Windows both use.
So what am I missing? Why did the Tcl maintainers stick with long for
Tcl_Time.sec? It could just be a holdover from before time_t existed or
really mattered, but perhaps they had a better for keeping it as a long.
> So at least, when using Tcl_GetTime(), which returns the time as
> Tcl_Time, everything should be fine. Note, that in your native time
> implementation, you assign to timePtr->sec with (time_t), which might
> be part of the problem you are experiencing.
Could be. I will try the no-mutex-timings and Ns_GetTimeFromTcl() approach
again, this time with Ns_Time.sec changed back to type long rather than
time_t.
> Probably, i should get a windows installation running, but the setup
> costs are quite high in terms of time and lack on windows-knowlege on
> my side.
Yeah. Maybe the Docker stuff Stephen showed us would make it easier?
Definitely see the notes I sent a while back on exactly what Microsoft
software to install. All the main stuff you need is available for free but
figuring out WHAT you're supposed to install is not easy.
Btw, if you do go that route, be aware that I am using
nmake -f Makefile.win32
for building and cleaning, but NOT for installing Naviserver. I have not
debugged the install commands of those two *.win32 makefiles at all, because
I have my own old Tcl script ("win32-install-nsd.tcl") for intalling on
Windows, which I was able to quickly adapt to Naviserver.
If you want that install script let me know. I haven't added it to
Mercurial yet because it is in CVS, and I'd like to nicely retain its full
history it, but haven't looked up how to best do that yet.
--
Andrew Piskorski <at...@pi...>
----------------------------------------------------------------------------
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI
DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you
Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI
DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
|
|
From: Andrew P. <at...@pi...> - 2014-10-08 17:04:42
|
On Wed, Oct 08, 2014 at 06:50:35PM +0200, Maurizio Martignano wrote: > Dear Andrew and Gustaf, > In due time, when you both are confident on the status of Naviserver > on Windows, I would try it inside my Windows-OpenACS distribution. That sounds excellent to me. My own use of Naviserver on Windows will be in a rather narrow application (not OpenACS; we use Linux for that), so it would be great to see it tested on a wider range of workloads. -- Andrew Piskorski <at...@pi...> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X