Re: [naviserver-devel] scheduler thread getting stuck

2020-06-03 Thread Andrew Piskorski
Is nsproxy supposed to work correctly on Windows?

Its test framework wants to use test-nsproxy.sh to set LD_LIBRARY_PATH,
which of course can't work on Windows.  But as I work around that,
when I run just the ns_proxy.test tests, I get this error:

  Assertion failed: sec >= 0, file time.c, line 344

Which gives this stacktrace when run under the WinDbg debugger:

: nsthread!Ns_IncrTime+0x6c [naviserver\nsthread\time.c @ 344]
: nsproxy!Ns_ModuleInit+0x7a76
: nsthread!NsThreadMain+0x77 [naviserver\nsthread\thread.c @ 236]
: nsthread!ThreadMain+0x6c [naviserver\nsthread\winthread.c @ 874]
: ucrtbased!thread_start+0x9c 
[minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 97]
: kernel32!BaseThreadInitThunk+0xd
: ntdll!RtlUserThreadStart+0x21

Weirdly, that stacktrace seems like it must be missing some
intermediate function calls, because nsproxy's Ns_ModuleInit()
definitely never calls Ns_IncrTime() DIRECTLY.  So I'm not sure what's
going on there either.

-- 
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-03 Thread Andrew Piskorski
On Mon, Jun 01, 2020 at 11:08:48AM -0400, Andrew Piskorski wrote:
> ## Last test that runs on Windows, it locks up forever:
> 
> http_persistent.test
> ns_sockioctl failed: no such file or directory
> while executing
> "ns_socknread $s"
> (procedure "client_readable" line 2)

For now I simply moved the entire http_persistent.test file out of the
way, so the server skips those tests.  With that, test server got
further, but eventually crashed with what looks like a null pointer
dereference, here:

  [03/Jun/2020:14:25:28][4844.2b10][-conn:test:default:1:229-] Notice: inside 
the filter 3.4
  ns_serverpath.test
  ns_set.test
  ns_sha1.test
  ns_sls.test
  ns_striphtml.test
  ns_thread.test

  [03/Jun/2020:14:25:28][4844.13bc][-tcl-nsthread:7-] Notice: update 
interpreter to epoch 1, trace none, time 0.219973 secs
  Assertion failed: (addr != ((void *)0)), file tclobj.c, line 325
  [03/Jun/2020:14:25:32][4844.1dd8][-tcl-nsthread:8-] Notice: update 
interpreter to epoch 1, trace none, time 3.902536 secs

The stack trace looked like this:

  ucrtbased.dll!07feedad41cf()Unknown
  libnsd.dll!Ns_TclSetAddrObj(Tcl_Obj * objPtr, const char * type, void * addr) 
Line 325  C
  libnsd.dll!NsTclThreadObjCmd(void * clientData, Tcl_Interp * interp, int 
objc, Tcl_Obj * const * objv) Line 239 C
  [External Code]
  libnsd.dll!CmdThread(void * arg) Line 1333  C
  nsthread.dll!NsThreadMain(void * arg) Line 236  C
  nsthread.dll!ThreadMain(void * arg) Line 874C

So that was inside Ns_TclSetAddrObj(), probably in the
"NS_NONNULL_ASSERT(addr != NULL);" line.  It was called from
NsTclThreadObjCmd(), in "case THandleIdx", line 238 in tclthread.c.
That presumably came from a Tcl "ns_thread handle" call, and there's
only one of those in the test suite, "test ns_thread-2.6" on line 70
of "ns_thread.test".  But I don't understand why that would throw a
null pointer exception!

Prior to that crash, various other interesting test failures cropped
up, including both "ns_listencallback-1.0" and "ns_schedule-2.1" below.
The ns_schedule-2.1 failure certainly sounds related to my original
problem of the scheduler thread getting stuck, but there's enough else
going on here that don't have any idea where the real source of the
problem might be.


 ns_listencallback-1.0 register FAILED
 Contents of test case:

set localhost [expr {[ns_info ipv6] ? "::1" : "127.0.0.1"}]
ns_log notice "open sockent on $localhost 7227"
set fds [ns_sockopen $localhost 7227]
lassign $fds rfd wfd
set size 0

if {[gets $rfd line] == -1} {
ns_log error "got no data"
} else {
incr size [string length $line]
puts $wfd "How are you?"
flush $wfd
gets $rfd line
incr size [string length $line]
}
return [list size $size]

 Result was:
size 0
 Result should have been (exact matching):
size 46
 ns_listencallback-1.0 FAILED


 ns_schedule-2.1 schedule proc: interval FAILED
 Contents of test case:

set id [ns_schedule_proc 1s {nsv_lappend . . ns_schedule-2.1}]
ns_sleep 2.5s
ns_unschedule_proc $id
nsv_get . .

 Result was:
ns_schedule-2.1
 Result should have been (glob matching):
ns_schedule-2.1 ns_schedule-2.1*
 ns_schedule-2.1 FAILED

-- 
Andrew Piskorski 


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