Re: [naviserver-devel] scheduler thread getting stuck

2020-06-08 Thread Gustaf Neumann

On 04.06.20 17:26, Gustaf Neumann wrote:

This sounds indeed related with the original problem.
The test registers a repeating proc (interval 1s),
but within in the time-range of 2.5s, it is executed
only once.

...

maybe i get on the weekend some access to a win environent.

i could use a windows machine over the weekend, but unfortunately,
this was very limited (windows 7, very small hd).

However, i was able to set everything up to be able to compile
NaviServer with msvc, but i was not able to run the regression tests
(path to long, etc.). When compiling with x64, there were many
warnings concerning the "sec" member in Ns_Time, which is
defined as long. Due to the memory model in windows 64
bit (LLP64) a long is there 32 bit, ... but an ns_time (e.g. the result
of time()) is 64 bit. This value is often supplied to the "sec" member.
So, i have modified the code to use "time_t" for the "sec" member,
... and many of the warnings disappeared.

Most other 64bit OS use LP64 (long is 64 bit), where assigning
time_t to long was not an issue.

This change will not solve all of the issues you are experiencing,
bit it might improve the situation for a few.

Background: The problem with LLP64 and using "long" for
sec is not new, many of the operations on Ns_Time were most
likely never working correctly under win64. But they started to
show up as a problem lately, since the newer code relies
more on this functions working correctly (among other things,
in the scheduler).

Hope that these changes helped a little.

all the best

-gn



___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel


Re: [naviserver-devel] scheduler thread getting stuck

2020-06-08 Thread Andrew Piskorski
On Mon, Jun 08, 2020 at 12:04:59PM +0200, Gustaf Neumann wrote:

> So, i have modified the code to use "time_t" for the "sec" member,
> ... and many of the warnings disappeared.

That's a big improvement, thank you, Gustaf!  The 22 regression tests
below used to fail, but now pass!

No change to the other failing tests, nor to the ones that we're
currently skipping with the notWin32 constraint.
E.g., test ns_thread-2.6 still triggers this:
  Assertion failed: tid != NULL, file tclthread.c, line 238


## Gustaf's 2020-06-07 changes fixed these test failures:
 ns_schedule-2.1 schedule proc: interval FAILED
 ns_time-1.2ms ns_time incr timeunit float+ms int FAILED
 ns_time-1.3ms ns_time incr timeunit int+ms int FAILED
 ns_time-1.3?s ns_time incr timeunit int+ms int FAILED
 ns_time-1.4-100ms ns_time incr timeunit 100ms int FAILED
 ns_time-1.4-10ms ns_time incr timeunit 10ms int FAILED
 ns_time-1.4-1ms ns_time incr timeunit 1ms int FAILED
 ns_time-1.4-0.1ms ns_time incr timeunit 0.1ms int FAILED
 ns_time-1.4-0.01ms ns_time incr timeunit 0.01ms int FAILED
 ns_time-1.4-0.001ms ns_time incr timeunit 0.001ms int FAILED
 ns_time-format-1.2 ns_time format positive microsecond FAILED
 ns_time-format-2.1 ns_time format negative second FAILED
 ns_time-format-2.2 ns_time format negative second with fraction FAILED
 ns_time-format-2.4 ns_time format negative microsecond FAILED
 ns_time-format-2.4-0.001ms ns_time format negative microsecond FAILED
 ns_time-diff-1 ns_time diff simple FAILED
 ns_time-diff-2 ns_time diff requires adjust FAILED
 ns_time-diff-3 ns_time diff subtract nothing FAILED
 ns_time-diff-4 ns_time diff add 1ms FAILED
 ns_time-diff-5 ns_time diff turn positive to negative FAILED
 ns_time-diff-6 ns_time diff make negative more negative FAILED
 ns_time-diff-9 ns_time diff turn negative to positive FAILED

-- 
Andrew Piskorski 


___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel


Re: [naviserver-devel] scheduler thread getting stuck

2020-06-08 Thread Gustaf Neumann

On 08.06.20 16:32, Andrew Piskorski wrote:

On Mon, Jun 08, 2020 at 12:04:59PM +0200, Gustaf Neumann wrote:

So, i have modified the code to use "time_t" for the "sec" member,
... and many of the warnings disappeared.

That's a big improvement, thank you, Gustaf!  The 22 regression tests
below used to fail, but now pass!

good news!

No change to the other failing tests, nor to the ones that we're
currently skipping with the notWin32 constraint.
E.g., test ns_thread-2.6 still triggers this:
   Assertion failed: tid != NULL, file tclthread.c, line 238

i am not surprised, since i have not changed anything around this.
The problem might have to to do with the different way of the
setup for tests. You might check whether "ns_thread handle"
in a classical setup (e.g. in a ds/shell) thows the same exception.

-gn



___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel


Re: [naviserver-devel] scheduler thread getting stuck

2020-06-08 Thread Andrew Piskorski
On Windows there are still a few compiler warnings that look a little
suspicious (below), but I don't see any good way to fix these.


cl /W3 /nologo /c /EHsc /MDd /Od /Zi /RTC1 /I "..\include" /I 
"C:\P\OpenSSL-Win64\include"  /I "C:\P\Tcl-64-8.6\include" /D "_WINDOWS" /D 
"TCL_THREADS=1"  /D "FD_SETSIZE=128" /D "_MBCS"  /D _CRT_SECURE_NO_WARNINGS /D 
_CRT_SECURE_NO_DEPRECATE /D "_DEBUG" /c /Foexec.o exec.c
exec.c(154): warning C4312: 'type cast': conversion from 'pid_t' to 'HANDLE' of 
greater size
exec.c(371): warning C4311: 'type cast': pointer truncation from 'HANDLE' to 
'pid_t'

cl /W3 /nologo /c /EHsc /MDd /Od /Zi /RTC1 /I "..\include" /I 
"C:\P\OpenSSL-Win64\include"  /I "C:\P\Tcl-64-8.6\include" /D "_WINDOWS" /D 
"TCL_THREADS=1"  /D "FD_SETSIZE=128" /D "_MBCS"  /D _CRT_SECURE_NO_WARNINGS /D 
_CRT_SECURE_NO_DEPRECATE /D "_DEBUG" /c /Fotls.o tls.c
tls.c(228): warning C4244: 'function': conversion from 'SOCKET' to 'int', 
possible loss of data
tls.c(376): warning C4244: 'function': conversion from 'SOCKET' to 'int', 
possible loss of data

cl /W3 /nologo /c /EHsc /MDd /Od /Zi /RTC1 /I "..\include" /I 
"C:\P\OpenSSL-Win64\include"  /I "C:\P\Tcl-64-8.6\include" /D "_WINDOWS" /D 
"TCL_THREADS=1"  /D "FD_SETSIZE=128" /D "_MBCS"  /D _CRT_SECURE_NO_WARNINGS /D 
_CRT_SECURE_NO_DEPRECATE /D "_DEBUG" /c /Fotclcrypto.o tclcrypto.c
tclcrypto.c(592): warning C4090: 'initializing': different 'const' qualifiers
tclcrypto.c(656): warning C4090: 'initializing': different 'const' qualifiers
tclcrypto.c(711): warning C4090: 'initializing': different 'const' qualifiers
tclcrypto.c(822): warning C4090: 'initializing': different 'const' qualifiers
tclcrypto.c(955): warning C4090: 'initializing': different 'const' qualifiers
tclcrypto.c(1011): warning C4090: 'initializing': different 'const' qualifiers
tclcrypto.c(1068): warning C4090: 'initializing': different 'const' qualifiers

-- 
Andrew Piskorski 


___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel


Re: [naviserver-devel] scheduler thread getting stuck

2020-06-08 Thread Andrew Piskorski
On Mon, Jun 08, 2020 at 05:46:54PM +0200, Gustaf Neumann wrote:
> >Assertion failed: tid != NULL, file tclthread.c, line 238

> You might check whether "ns_thread handle"
> in a classical setup (e.g. in a ds/shell) thows the same exception.

Good idea.  I started up NaviServer with the same test.nscfg config
file, but using the installed binaries instead of the "nmake -f
Makefile.win32 _test" approach.  Then I typed "ns_thread handle" at
the control port prompt.

That threw the exact same exception as before.  Under WinDbg it also
looks the same, inside Ns_ThreadSelf() wPtr appears to be defined, but
threadPtr and wPtr->self are null.

-- 
Andrew Piskorski 


___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel


Re: [naviserver-devel] scheduler thread getting stuck

2020-06-08 Thread Gustaf Neumann

On 08.06.20 19:39, Andrew Piskorski wrote:

On Windows there are still a few compiler warnings that look a little
suspicious (below), but I don't see any good way to fix these.


it is not hard to silence these cases (at least one of these appeared 
multiple times on stackoverflow), but these are not related to the 
errors you have reported.


i hope, the next weekend, i can get a better PC for continuing on this.

-g



___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel